Return-Path: 
 <ant-dev-return-18419-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 24717 invoked by uid 500); 12 Oct 2001 23:18:01 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 24664 invoked from network); 12 Oct 2001 23:18:01 -0000
Message-ID: <000501c15373$df699e70$0100a8c0@jose>
From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
To: <ant-dev@jakarta.apache.org>
References: <F483AD0DB13BD411A38300104B2E651E8F0E75@valkyrie.wamnet.com>
Subject: Re: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date: Fri, 12 Oct 2001 16:45:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

From: "Tim Dawson" <tdawson@wamnet.com>

> responses to Jose's comments inline...
>=20
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> > > 2. Startup Deployment
> > >=20
> > > Alter Project.java to discontinue the use of the=20
> > defaults.properties files,
> > > and instead do a=20
> > ClassLoader.getResources("meta-inf/antlib.xml"), and
> > > process each of those on startup.
> > >=20
> > > This will occur for any jar file found in the java startup=20
> > classpath.
> > > Currently this means anything in ANT_HOME/lib, or ant.jar=20
> > and optional.jar.
> > > In the future (ant2), who knows.  NOTE: This last point=20
> > 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=20
> > knows I won't.
> > > :-)
> > >=20
> >=20
> > I do not really like this one too much. As I said before I=20
> > prefer libraries other than core to be mentioned in the build=20
> > file so people know what they need.
>=20
> does this include optional?  if so, under ant 1.5, how will we manage =
to do
> that when the getResources() will return both of the deployment =
descriptors?
>=20

Yes, in my opinion it should include optional.jar. As with respect to =
getResources() what I am advocating is not to use it at all. Moreover we =
should not be putting things in the classpath at all. I still believe we =
should gear ANT to not require changes in the CLASSPATH at all. Any real =
dependencies of the core, should be defined and resolved by core itself. =
Either by using Class-Path entry in the manifest or some simillar means. =
Notice this is not extensions in the traditional sense.

> while it has been a popular sentiment in this group to prevent ant =
users
> from doing "bad" things, sometimes its just simpler and better to =
document
> what the "right" way is, and state that if you do something the =
"wrong" way
> you may be screwed in the future, as will inevitably happen to people =
doing
> this once we get the ant launching classpath stuff straightened out.
>=20
> >=20
> > > 3. JDK 1.1 Compatibility
> > >=20
> > > Update the classloader to support getResources() under 1.1.
> > >=20

GetResources return URLs, are there in 1.1 URLConnection implementations =
that understand the "jar:" protocol?

> > > 4. Antlib Task
> > >=20
> > > Add a new task "tasklib" which can be used to load a jar=20
> > file containing ant
> > > tasks and datatypes.  A file attribute can specify a jar=20
> > file, or a nested
> > > <path> element can be used as well.
> > >=20
> > > e.g.
> > >   <antlib file=3D"foo.jar"/>
> > >   <antlib>
> > >     <classpath refid=3D"main.classpath"/>
> > >   </antlib>
> > >=20
> > > The <antlib> task must appear inside a <target>.  NOTE: to=20
> > avoid confusion,
> > > I'll add that this is entirely possible. See other notes in=20
> > the thread that
> > > discuss how to use taskdef inside a target.
> > >=20
> >=20
> > Why does it need t be inside a <target>? I think that=20
> > <taskdef>, <typedef> and <antlib> should all work the same=20
> > and be inside and outside targets, depending on when you know=20
> > the class or library will be ready for use.
>=20
> well, I suppose it doesn't. I'm just lobbying in a few threads that we
> should remove the capability to have anything outside a target. I =
think its
> ugly and hackish to do it, and anyway its completely unclear as to =
what's
> allowed outside a target.
>=20

I only advacate that it should work like the other declarating tasks. =
Uniformity is the point here.

> > > 5. Task Name Collisions
> > >=20
> > > The antlib task must also provide the capability to=20
> > 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.
> > >=20
> > > e.g.
> > >   <antlib file=3D"foo.jar">
> > >     <taskalias libtask=3D"task1" name=3D"foo-task1"/>
> > >     <typealias libtype=3D"type1" name=3D"foo-type1"/>
> > >   </antlib>
> > >=20
> >=20
> > I like things as simple as possible. One charasteristic of=20
> > ANT is that tasks and datatypes cannot have the same name,=20
> > since the namespace is the same. That means that there is no=20
> > reason for assuming that in one library you will have tasks=20
> > and types with the same name hence, we do not need to=20
> > diferenciate them for the purpose of aliasing. So we can as well do:
> >=20
> >     <antlib file=3D"foo.jar">
> >         <alias name=3D"task1" as=3D"fooTask1" />
> >         <alias name=3D"type1" as=3D"fooType1" />
> >     </antlib>
>=20
> I much prefer "name" and "as" to my original "libtask" and "name"
> attributes. Great idea!
>=20
> As for dropping <taskalias> and <typealias> in favor of just <alias>, =
yeah,
> my primary concern was collisions between tasks and types with the =
same
> name. (Is this possible? it would be extremely bad form, IMHO)
>=20
> > What this means is that users do not need to know if a=20
> > particular element is a task a type or in the future=20
> > something else. Unless of course one needs to know for its usage.
>=20
> Since the alias isn't required, they presumably would already know its =
usage
> anyway.
>=20
> > Question, what should be done in the case of collisions?=20
> > Which definition wins, the new library or the existing declaration?
> > Maybe we need an override attribute for the library =
override=3D"true".
> >=20
> > How do you plan to resolve collisions if autoloading is supported?
>=20
> I guess it wasn't specified, but I was thinking that collisions would =
cause
> a failure same as it would with a <antlib> without an alias.
>=20

But that would mean ther is no way to start ANT, just because you put =
one too many jars in the system. That sounds really bad to me.

> Tim
>=20