I think optional packages are just as important as core packages, but one thing I'd like to just insert in this discussion is that emailing a message does not seem to me to be something that should be included as a core taskdef. It makes more sense to include this as an optional taskdef because it does not increase the runtime requirements ( See Duncan's spec doc at http://jakarta.apache.org/cvsweb/index.cgi/jakarta-ant/spec/core.html?rev=1. 1&content-type=text/vnd.viewcvs-markup ).
Further down that road, I don't think that the Ant project should contain any code that deals specfically with sending email when there is an established and widely embraced standard in JavaMail. We could reimplement this under APL in the future, and in my case sending a mail attachment is a feature which would be used immediately for distributing a release to a number of interested parties. It may seem like overkill to some, but to others it may be one of those features that clearly establishes Ant as the tool to use. The "core" and "optional" distinction does seem a bit arbitrary, but it is useful in the following sense. Optional packages are just that, they do not sepcifically relate to the core ability of Ant, build management and file operations. Tim O'Brien [EMAIL PROTECTED] -----Original Message----- From: Jason Hunter [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2000 12:35 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-ant/src/main/com/oreilly/servlet MailMessage.java Conor MacNeill wrote: > > 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. I think it's a terminology issue. There are three kinds of Ant tasks: * Core tasks, provided with Ant and available to everyone * Optional tasks, built if and only if certain libraries are on the person's machine * Project-specific tasks, things needed by a project but not generally useful I was stating that whether something was "core" or "project-specific" should be decided on the merits of the task. "Optional" is a crazy middle ground. If something is worth being core, then every effort should be taken to have the necessary JARs bundled with Ant, because you should be able to build your project using "core" tasks and expect it to build on any system. If a task is project-specific, then it shouldn't leave your project. Optional tasks should only be used as a very last resort when something merits being core but there's no way to provide the necessary supporting JAR. And even then I don't like the idea very much. :-) > 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? No restrictions on making changes, except a note at the top of the file asking the maker of the change to coordinate with Servlets.com development if possible. But really, we're talking about a single file that does a specific well-defined task, so I'm not real worried about divergence. That is a reason to move it to org.apache.* though, so people won't be confused if there ever is divergence. > > 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). Optional tasks at runtime? Sounds like a minefield. > If Intersourcing, as you called it, involves copying source code, then I > would have reservations about it. It's new territory, but generally it involves branching and shipping a product based on the branch with cherrypick bug fixes. If you think about it, that's how we release Tomcat -- create a release branch and fine tune it while active development progresses on the trunk. -jh-
