ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: cvs commit: jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/builder ant1convert.xsl
Date Thu, 21 Mar 2002 00:53:15 GMT

> -----Original Message-----
> From: Darrell DeBoer []
> Sent: Wednesday, 20 March 2002 1:42 PM
> To: Ant Developers List
> Subject: Re: cvs commit:
> jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/bu
> ilder ant1convert.xsl

> >
> > However, we should be able to make ant1compat.atl a .jar now.  Then you
> > should be able to simply drop in an antlib and have it work, 
> regardless of
> > whether it contains ant 1 or ant 2 tasks.
> >
> > Not sure how the dependency on tools.jar and an XML parser will fit in
> > there.  An extension would probably work for them.
> I quickly tried this out - the tools.jar extension didn't seem to 
> be loaded 
> when I renamed to ant1compat.jar. Anyhow, we probably need a more general 
> solution to the problem of adding antlibs which depend on other 
> antlibs.  An 
> example would be if you extended a antlib with a new different task, and 
> wanted to be able to share datatype references between the new 
> and existing 
> tasks. (You don't want to always force the original antlib to be 
> a .jar, and 
> reside in the top-level classloader).
> I don't think he way extensions currently work will work, because 
> the classes 
> will be loaded separately for each antlib, so instances couldn't 
> be shared. 
> It seems that we need a way to declare that Antlib-A "depends" on 
> antlib-B, 
> so that antlib-A could be loaded in a ClassLoader that was a child of the 
> antlib-B's classLoader.

The classloader stuff definitely needs more work.  We have 3 issues to deal with:

* How do we declare the dependencies of a jar file (given that an antlib is a jar file)?

* How do we map from a dependency declared by a jar file, to the set of jar files that make
up that dependency?

* How do we ensure that each jar file, when used as a dependency, appears at most once in
the classloader hierarchy?

For declaring the dependencies, I think the extension mechanism is fine.  It's a standard
(more or less), it uses symbolic names to specify dependencies, and it allows versioning of
dependencies.  Syntactically, it's a little awkward, but it's good enough.

We certainly want the mapping from extension name (and version) -> jar files to be pluggable,
and we want to allow more than one mapping at runtime.  We have plenty of options for the
mappings, but as defaults I think something like these would be useful:

* The mapping currently provided by DefaultExtensionManager, which uses the jars in the ext/

* A couple of special case mappings to tools.jar, and to a JAXP 1.1 impl.

* Implicit mapping from antlib name -> antlib.

* Probably some light-weight mechanism for bundling up a set of jars as an extension, without
needing to mess with their manifests.  Maybe add them to a subdirectory of ext/ and use the
subdir name as the extension name.

Whatever.  The point is to make this pluggable.

As far as the classloader hierarchy goes, I'd like to try using multi-parent classloaders,
to see what grief that causes.

I've been meaning to make ClassLoaderManager responsible for all this, just haven't gotten
around to it.  I'd also like to start exposing some of this to the build file.  For example,
adding a specialised path that evaluates to the classpath for an extension:

       <library-path libname="" />
       <library-path libname="jaxp" version="1.1+" />
       <library-path libname="antlib.core" />


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message