Responses to Ovidiu's comments inline... > -----Original Message----- > From: Ovidiu Predescu [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 11, 2001 6:02 PM > To: Tim Dawson > Cc: '[EMAIL PROTECTED]' > Subject: Re: SUMMARY: loading tasks from jars for Ant 1.5 summary > feedback > > > I don't have committer access, but here I am with my "vote" and > comments on the proposal. > > On Thu, 11 Oct 2001 16:24:36 -0500, Tim Dawson > <[EMAIL PROTECTED]> wrote: > > > In summary of the previous thread the proposal is now: > > > > ------------ > > 1. Deployment Descriptor > > > > 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="..."/> > > <type name="..." class="..."/> > > <type name="..." class="..."/> > > </antlib> > > > > NOTE: datatype shortened to "type" from previous proposal. > > Looks good to me. > > > 2. Startup Deployment > > > > 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. > > > > This will occur for any jar file found in the java startup > classpath. > > Currently this means anything in ANT_HOME/lib, or ant.jar > and optional.jar. > > In the future (ant2), who knows. NOTE: This last point > will probably be > > controversial, because people could put any third party jars inside > > ANT_HOME/lib. If you don't like this, don't do it. Lord > knows I won't. > > :-) > > OK. > > > 3. JDK 1.1 Compatibility > > > > Update the classloader to support getResources() under 1.1. > > OK. > > > 4. Antlib Task > > > > Add a new task "tasklib" which can be used to load a jar > file containing ant > > tasks and datatypes. A file attribute can specify a jar > file, or a nested > > <path> element can be used as well. > > > > e.g. > > <antlib file="foo.jar"/> > > <antlib> > > <classpath refid="main.classpath"/> > > </antlib> > > > > The <antlib> task must appear inside a <target>. NOTE: to > avoid confusion, > > I'll add that this is entirely possible. See other notes in > the thread that > > discuss how to use taskdef inside a target. > > Why come up with <antlib> and not use <taskdef>? They do the same > thing.
The problem with that is implementation... how do you specify that taskdef should use the deployment descriptor? That works fine with <taskdef lib="">, when you're specifying a jar file, but it breaks the ability (which I wasn't too fond of anyway) of using nested path elements. > > > 5. Task Name Collisions > > > > The antlib task must also provide the capability to > overrride the task names > > defined in the deployment descriptor. If a tasklib is loaded and a > > collision is detected without an alias, the build fails. > > > > e.g. > > <antlib file="foo.jar"> > > <taskalias libtask="task1" name="foo-task1"/> > > <typealias libtype="type1" name="foo-type1"/> > > </antlib> > > How about if the user wants to override the definition of an already > defined task? Should we have an attribute "override" for <taskalias> > that specifies that overriding is required? > > I would certainly like to have the ability to extend certain tasks by > implementing a derived class or an entirely new class. -1 on that! I originally thought this would be nice too, but as I thought of it, it would really be a problem for maintainability -- especially if you used the drop-in-ant-home-lib trick. Think of it... if I made my own <fail> which has if/unless capabilities, and I use that all over in my build.xml file, and another developer checks out my code & doesn't get $ANT_HOME/lib/mytasks.jar, and the build.xml looks bad because it doesn't know what the heck to do with the if/unless! > > 6. Optional.jar > > > > Separate the definition of the optional tasks and types into the > > meta-inf/antlib.xml file in the optional.jar. > > OK. > > > 7. Supporting Tasks > > > > Supporting tasks for generating the antlib jar file and related > > documentation are out of scope for this proposal. Once this > is approved, > > then we can begin the work on that. > > Sounds good. > > > Due to the length of the previous thread, I think we need > to start the vote > > over. Please reply with your +1, 0, or -1 vote to the > group. OR, feel free > > to continue the thread if I've missed anything or until we > get consensus. > > :-) > > There's one more thing I'd like to see in this proposal. What happens > with tasks which depend on the existence of other jar files being > loaded? > > One such example would be a <cocoon> task to run Cocoon2 from within > Ant to generate documentation. The task itself depends on the Cocoon > libraries being loaded. A WAR file instead of a JAR file would solve > this problem, as all the jar dependencies could be placed in > WEB-INF/lib. From an implementation perspective, we can borrow code > from Tomcat's classloader to implement it. as with many of the other suggestions, this can be done currently with the manifest for the jar file. (another reason why I like using <antlib> and not allowing the nested path element) in particular, specify a classpath. this is an exerpt from one of mine: Manifest-Version: 1.0 Class-Path: xerces.jar xalan.jar jaxb-rt-1.0-ea.jar > Any thoughts on this one? > > Regards, > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > http://orion.rgv.hp.com/ (inside HP's firewall only) > http://sourceforge.net/users/ovidiu/ (my SourceForge page) > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, > Emacs, other stuff) >
