ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date Thu, 11 Oct 2001 23:01:45 GMT
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 <> 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 to discontinue the use of the 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.
> :-)


> 3. JDK 1.1 Compatibility
> Update the classloader to support getResources() under 1.1.


> 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

> 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.

> 6. Optional.jar
> Separate the definition of the optional tasks and types into the
> meta-inf/antlib.xml file in the optional.jar.


> 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

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.

Any thoughts on this one?

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

View raw message