> -----Original Message----- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 10, 2001 10:21 AM > To: [EMAIL PROTECTED] > Subject: Re: PROPOSAL: loading tasks from jars for Ant 1.5 > > > From: "Conor MacNeill" <[EMAIL PROTECTED]> > > 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
