Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: antlibs and classloaders #2
Date: Mon, 17 May 2004 15:01:16 +0100
Message-ID: <F3D701FEF0483B4AAA11A18CE328461B0781CD@leeds.cellectivity.com>
Thread-Topic: antlibs and classloaders #2
Thread-Index: AcQ8CorYxo2QZMQGQ8is0IdoFyENxAACkATw
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>

Mariano,

I also agree with you and what you are saying. However I think
we have several different parts of the proposal that are too loose
and hence allow to break this general concept as you put it.

For example we have:

1) The jars containing the antlig code (which is defined by a classpath
or classloader)

2) The URI for the antlib, which can be specified implicitely with an
antlib:uri or
explicitly with the uri parameter of typedef. Using typedef, you can
load several
antlibs to the same namespace and such.

3) antlib.xml file or resource which contains the XML definitions of the
tasks and types.

Now, all this things can be used in a systemetic way to achieve your
goals (I think),
but they can be used to act in a quite different way and bringing all
kinds of problems.

So, are our objectives just the suggested user patterns for ANTLIBs or
are they
mandatory behaviour of antlibs. Depending on what we want, it will
change the way we
teach people how to write effective reusable antlibs. As oppose to "only
will work on my machine"
kind of antlibs.

This is what I do not think we have a clear understanding. How are
people to use all this moving
parts in a consistent way that promotes reusability, etc, etc.

Jose Alberto

> -----Original Message-----
> From: Mariano Benitez [mailto:mariano@fuegolabs.com]=20
> Sent: 17 May 2004 13:29
> To: Ant Developers List
> Subject: Re: antlibs and classloaders #2
>=20
>=20
>=20
> >This things sound like we are using the wrong abstraction here.=20
> ><typedef/> inside an <antlib/> should use the antlib=20
> classloader as the=20
> >parent for any subsequent classloader.
> >
> >I do not see why that should cause an infinite recursion.
> >
> >I feel like we have a conceptual mismatch between antlib=20
> "the jar" with=20
> >the code, and antlib "the resource with the XML definitions". We are=20
> >not treating them in a symetric way or as a unit. And hence=20
> we are get=20
> >into all this conflicting behaviour.
> > =20
> >
>=20
> I would like to pick from here and try to describe my=20
> understanding of=20
> the concepts.
>=20
> Antlib: I see this as a a definition of tasks within a namespace that=20
> involves all the jars required to resolve the execution of=20
> the tasks. To=20
> put it plainly, I see it as the antlib.xml with a classpath.
>     So for me that defines completely the antlib and the=20
> extra classpath=20
> should be added to the antlib classpath.
>=20
>     Also, for me is accidental that the antlibs should be=20
> located in the=20
> $ANT_HOME/lib or in a -lib <path>, actually the antlib=20
> definition should=20
> start from the antlib.xml, wherever it is, and then create a=20
> classloader=20
> based on the antlib definition.
>=20
>     For the special case were the antlib jars are located in the base=20
> ant classpath ($ANT_HOME/lib or -lib <path>) I would not=20
> allow adding a=20
> classpath since the antlib should be completely contained within the=20
> base ant classpath, only when the antlib jars are outside I=20
> would allow=20
> defining an extra classpath.
>=20
>     Also, defining antlibs in either way (being inside base ant=20
> classpath or outside) should behave the same way, they should be=20
> idempotent, meaning that once they are defined, they should not be=20
> overriden, I understand that it is not wise to use the same uri for=20
> different antlibs, the user should always try to pick unique=20
> names for=20
> the antlibs, otherwise we go back to a single namespace.
>=20
> This is my understanding of antlibs, it is probably out of synch with=20
> what you envision on this, but I wanted to let you know what=20
> I thought=20
> antlibs were about.
>=20
> My 2 cents.
> MAriano
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20
>=20

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