ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date Fri, 12 Oct 2001 12:39:18 GMT
Responses to Ovidiu's comments inline...

> -----Original Message-----
> From: Ovidiu Predescu [mailto:ovidiu@cup.hp.com]
> Sent: Thursday, October 11, 2001 6:02 PM
> To: Tim Dawson
> Cc: 'ant-dev@jakarta.apache.org'
> 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 
> <tdawson@wamnet.com> 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 <ovidiu@cup.hp.com>
> 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)
> 

Mime
View raw message