ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: [PROPOSAL] Optional Tasks
Date Wed, 13 Dec 2000 21:38:07 GMT
> From: Siberski, Wolf [mailto:Wolf.Siberski@tui.de]
 
> 
> > 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

-1, the definition cannot be "what is needed to build ANT". Is has to be
based on what is needed to build a reasonable application that does not
require some external or optional tool during the build process.
Using ANT as an approximation is one thing, but it cannot be the begining
and end. In particular, what do you mean by building ANT? just CORE or 
the whole of ANT (optionals included)?

We need a more proper definition that means something for users of ANT and
not developers of ANT. Something people can count on when they look at
ANT as a tool for their projects.

> 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.
> 

Jose Alberto

Mime
View raw message