Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Subject: RE: cvs commit:
 jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/builder
 TransformingProjectBuilder.java ant1convert.xsl DefaultProjectBuilder.java
 Resources.properties
Date: Thu, 21 Mar 2002 10:53:15 +1000
Message-ID: <CLEMKEJLBJDGBHEDNCPHOEFHEHAA.adammurdoch_ml@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <200203200343.g2K3hF611522@mail016.syd.optusnet.com.au>
Importance: Normal


> -----Original Message-----
> From: Darrell DeBoer [mailto:darrell@apache.org]
> 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
>=20

> >
> > 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,=20
> 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.
>=20
> I quickly tried this out - the tools.jar extension didn't seem to=20
> be loaded=20
> when I renamed to ant1compat.jar. Anyhow, we probably need a more =
general=20
> solution to the problem of adding antlibs which depend on other=20
> antlibs.  An=20
> example would be if you extended a antlib with a new different task, =
and=20
> wanted to be able to share datatype references between the new=20
> and existing=20
> tasks. (You don't want to always force the original antlib to be=20
> a .jar, and=20
> reside in the top-level classloader).
>=20
> I don't think he way extensions currently work will work, because=20
> the classes=20
> will be loaded separately for each antlib, so instances couldn't=20
> be shared.=20
> It seems that we need a way to declare that Antlib-A "depends" on=20
> antlib-B,=20
> so that antlib-A could be loaded in a ClassLoader that was a child of =
the=20
> antlib-B's classLoader.
>=20

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=3D"sun.tools" />
       <library-path libname=3D"jaxp" version=3D"1.1+" />
       <library-path libname=3D"antlib.core" />
   </classpath>
</javac>


Adam


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>