> -----Original Message-----
> From: Darrell DeBoer [mailto:[EMAIL PROTECTED]
> 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 TransformingProjectBuilder.java ant1convert.xsl
> DefaultProjectBuilder.java Resources.properties
>
> >
> > 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/ directory.
* 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:
<javac>
<classpath>
<library-path libname="sun.tools" />
<library-path libname="jaxp" version="1.1+" />
<library-path libname="antlib.core" />
</classpath>
</javac>
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
