ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: PROPOSAL: loading tasks from jars for Ant 1.5
Date Wed, 10 Oct 2001 18:42:56 GMT
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Wednesday, October 10, 2001 10:21 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: PROPOSAL: loading tasks from jars for Ant 1.5
> 
> 
> From: "Conor MacNeill" <conor@cortexebusiness.com.au>
> > Tim Dawson wrote:
> > 
> > > In summary of the previous thread the recommendation is this:
> > > 
> > > 1. Specify a deployment descriptor for an antlib jar. 
> This would reside in
> > > "meta-inf/antlib.xml" and have a simple structure:
> > > 
> > > <antlib version="1.0">
> > >    <task name="..." class="..."/>
> > >    <task name="..." class="..."/>
> > >    <datatype name="..." class="..."/>
> > >    <datatype name="..." class="..."/>
> > > </antlib>
> > > 
> > > 2. Alter Project.java to discontinue the use of the 
> defaults.properties
> > > files, and instead do a 
> ClassLoader.getResources("meta-inf/antlib.xml"), and
> > > process each of those on startup.
> > > 
> 
> Is this assumming all jars in $ANT_HOME/lib are in the 
> CLASSPATH? I would prefer if somehow we manage to not depennd 
> on this and at the end of the day we work towards eliminating 
> the need for CLASSPATH manipulation.

My thought was that the auto-loading (without the explicit declaration of an
<antlib> task in the build.xml) would simply use whatever is in the
classpath.  Currently, all jars in $ANT_HOME/lib are included, so that was
my plan.

I'm not certain what along these lines is in the works for removing
classpath manipulation, but I think that explicit declarations in the build
file should take care of that.

> > > 3. Add a new task "antlib" which can be used to load a 
> jar file containing
> > > ant tasks and datatypes.  This would be used in case 
> someone doesn't want to
> > > drop their antlib into $ANT_HOME/lib.
> > > 
> > > e.g.
> > >   <antlib file="foo.jar"/>
> > > 
> > > 4. Separate the definition of the optional tasks and 
> types into the
> > > meta-fin/antlib.xml file in the optional.jar.
> > > 
> > > Please reply with your +1, 0, or -1 vote to the group.
> > > 
> > 
> > 
> > I agree in general. I think, however, once we adopt this 
> mechanism we 
> > would almost immediately need to handle name collisions in 
> the <task> 
> > and <datatype> definitions. Your proposal does not cater for this.
> > 
> 
> One simple proposal would be as you say, to allow aliasing:
> 
>     <antlib file="foo.jar">
>      <task name="copy" alias="copy2" />
>      <datatype name="fileset" alias="myveryspecialfileset" />
>     <antlib/>

I like this -- it allows someone to "override" an ant task, for example if
half this group wanted to add an if/unless attribute to <fail>. :-)

> This lives open the problem of how to deal with "installed" 
> libraries, but since I thing we should explicitly declare 
> them just so people know what is needed to run the thing, 
> that would live only ANT Core to be auto-installed.

Actually, I'm perfectly happy with that as well.  Some people might want at
least the optional tasks to be auto-installed, but frankly, I'd like to know
when looking at a buildfile if it uses some of the optional tasks.

Tim

Mime
View raw message