> Jose Alberto Fernandez wrote: > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > > > > Jon Stevens <[EMAIL PROTECTED]> wrote: > > > > > The definition of a "core" task is a task that Ant really cannot > > > live without. This would be similar to taglibs that are part of the > > > core JSP specification. [snip] > > > > And then there is a bunch of tasks that are not needed to build Ant > > and that are not related to a specific product either. <rmic>, <war>, > > <exec>, <native2ascii> and so on. They should go into the repository > > of optional tasks as well. > > > > I do not think I agree with your interpretation of the definition of core > vs. optional. Just to say that only things needed TO BUILD ANT are core > seems to me to be a very bad definition of what the core is. So what > happens if some other task that was not needed today becomes needed for > building ANT in the future, do we have to move it from the optioal package > to core? > I have similar doubts about this task partition, but maybe we can solve the problem by using a completely different approach.
My suggestion would be to use a package naming schema which only reflects the kind of task, but not their status regarding core, optional, etc. That would mean we have packages like org.apache.tools.ant.taskdefs.java for Java, Javac, Rmic, etc. org.apache.tools.ant.taskdefs.file for Rename, Copy, Chmod, etc. org.apache.tools.ant.taskdefs.scm for Cvs, P4Sync (Perforce), etc. Now we still have the packaging and dependency problem, but for this problem we only need a mechanism which partitions the tasks into task collections packaged as jar-Files (this is already planned for optional tasks, isn't it?). E.g., we could have anttasks.jar all tasks needed to build ant ejbtasks.jar all tasks needed to develop/deploy EJBs installtasks.jar all tasks needed to use Ant like InstallShield vajtasks.jar all tasks used for Visual Age for Java integration There's no need to put all tasks of one package into the same jar. Maybe it also makes sense to have overlapping task collections. All task collection jars which rely only on the JDK could and should IMHO be provided by the nightly build, while tasks collection jars relying on external libs would only be provided with releases (if at all). Each jar would have its own Ant build file, so the user in need for an up-to-date version of a jar with external dependencies could get the sources for just this jar and build it himself (no need to build the complete Ant for the 'mere mortals'). It sounds extreme, but I'd prefer to include no task at all in the ant.jar. I think there is no single task which is needed by all Ant users. Especially for the use as installer there should be no unneeded task included. Users wanting to build Ant with Ant could download anttasks.jar to get everything they need. The Ant 'engine' itself needs no task at all. But with the package naming schema proposed this becomes a nearly unrelated discussion. Besides, it wouldn't be such an important decision anymore, because the task packaging would be easily changeable. A third - also only slightly related - question is how to organize the CVS tree. Wolf
