Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <002601c06508$6fc948e0$095b900f@loughrans3>
From: "Steve Loughran" <steve_l@iseran.com>
To: <ant-dev@jakarta.apache.org>
References: <3.0.6.32.20001213235213.0098b700@latcs2.cs.latrobe.edu.au>
Subject: Re: [PROPOSAL] Optional Tasks
Date: Wed, 13 Dec 2000 13:27:26 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> At 01:16  13/12/00 +0100, Siberski, Wolf wrote:
> >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').

+1 too.
My only concern is that the add on tasks should be rebuilt regularly simply
as a form of regression testing, and so that when you get the nightly build
you can grab a jar of tasks which works with it. Otherwise you get into
jar-version-hell, with the mail list full of cries for help like "I'm
running ant2.3 with ejbtasks and task 'restart-servers' doesn't work"
because the user is still using ejbtasks 2.2...

Actually that raises another issue -all jars should include versions in the
manifest; ant -version should extract and print those versions out. That way
we can track down jar version issues when they arise.

-steve

------------
"plan on your service having a regular downtime. It will anyway"
Alpine Cycling  http://www.iseran.com/Atlas/