> From: Jason Hunter [mailto:[EMAIL PROTECTED] > > > Conor MacNeill wrote: > > > > Jason, > > > > Why not just make this an optional task. That way you can keep > the code in > > one place and under your control whilst making it available to > ant users who > > have installed your package. > > Whether a task should be optional or not should be dependent on the > merits of the task, not on what's easiest for integration.
I find that a strange statement. Optional tasks are not assumed to be less meritorious, IMHO. As I have viewed optional tasks, it is simply assumed that not every ant user will have the necessary packages installed on their system for those tasks to compile. So I do view optional tasks as a system for making tasks available where a package may or may not be present. I'm not sure that copying your source code into a system which might need to send email is a good idea. Duplicating code and then trying to keep them in sync is a hassle. For me, one of the important issues will become change management of this code. Will there be restrictions on making changes to this code in the ant source tree? If not, how will you stop them diverging? If changes are allowed, how will they be kept in sync with your source tree? > I'm sure in > this case we can solve the integration issue, and I personally think > sending mail is something qualifying as a core task, as async > notification of an official build finishing is quite standard. > Sure, that is a nice feature and where it is required, people could install the package to make it happen. There is an issue, however, in that optional tasks is currently a compile time concept. Perhaps it might be good to have optional tasks at runtime (i.e. their presence is ignored if there is no appropriate class available, without halting the build). If Intersourcing, as you called it, involves copying source code, then I would have reservations about it. Cheers Conor
