ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siberski, Wolf" <Wolf.Siber...@tui.de>
Subject RE: [PROPOSAL] Optional Tasks
Date Wed, 13 Dec 2000 12:16:19 GMT
> Jose Alberto Fernandez wrote:
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > 
> > 
> > Jon Stevens <jon@latchkey.com> 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

Mime
View raw message