Return-Path: 
 <ant-dev-return-18393-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 85641 invoked by uid 500); 12 Oct 2001 12:55:30 -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 85629 invoked from network); 12 Oct 2001 12:55:28 -0000
Message-ID: <F483AD0DB13BD411A38300104B2E651E8F0E75@valkyrie.wamnet.com>
From: Tim Dawson <tdawson@wamnet.com>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date: Fri, 12 Oct 2001 07:55:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

responses to Jose's comments inline...

> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Thursday, October 11, 2001 9:28 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: SUMMARY: loading tasks from jars for Ant 1.5 summary
> feedback

> > 2. Startup Deployment
> > 
> > Alter Project.java to discontinue the use of the 
> defaults.properties files,
> > and instead do a 
> ClassLoader.getResources("meta-inf/antlib.xml"), and
> > process each of those on startup.
> > 
> > This will occur for any jar file found in the java startup 
> classpath.
> > Currently this means anything in ANT_HOME/lib, or ant.jar 
> and optional.jar.
> > In the future (ant2), who knows.  NOTE: This last point 
> 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 
> knows I won't.
> > :-)
> > 
> 
> I do not really like this one too much. As I said before I 
> prefer libraries other than core to be mentioned in the build 
> file so people know what they need.

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?

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.

> 
> > 3. JDK 1.1 Compatibility
> > 
> > Update the classloader to support getResources() under 1.1.
> > 
> > 4. Antlib Task
> > 
> > Add a new task "tasklib" which can be used to load a jar 
> file containing ant
> > tasks and datatypes.  A file attribute can specify a jar 
> file, or a nested
> > <path> element can be used as well.
> > 
> > e.g.
> >   <antlib file="foo.jar"/>
> >   <antlib>
> >     <classpath refid="main.classpath"/>
> >   </antlib>
> > 
> > The <antlib> task must appear inside a <target>.  NOTE: to 
> avoid confusion,
> > I'll add that this is entirely possible. See other notes in 
> the thread that
> > discuss how to use taskdef inside a target.
> > 
> 
> Why does it need t be inside a <target>? I think that 
> <taskdef>, <typedef> and <antlib> should all work the same 
> and be inside and outside targets, depending on when you know 
> the class or library will be ready for use.

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.

> > 5. Task Name Collisions
> > 
> > The antlib task must also provide the capability to 
> 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.
> > 
> > e.g.
> >   <antlib file="foo.jar">
> >     <taskalias libtask="task1" name="foo-task1"/>
> >     <typealias libtype="type1" name="foo-type1"/>
> >   </antlib>
> > 
> 
> I like things as simple as possible. One charasteristic of 
> ANT is that tasks and datatypes cannot have the same name, 
> since the namespace is the same. That means that there is no 
> reason for assuming that in one library you will have tasks 
> and types with the same name hence, we do not need to 
> diferenciate them for the purpose of aliasing. So we can as well do:
> 
>     <antlib file="foo.jar">
>         <alias name="task1" as="fooTask1" />
>         <alias name="type1" as="fooType1" />
>     </antlib>

I much prefer "name" and "as" to my original "libtask" and "name"
attributes. Great idea!

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)

> What this means is that users do not need to know if a 
> particular element is a task a type or in the future 
> something else. Unless of course one needs to know for its usage.

Since the alias isn't required, they presumably would already know its usage
anyway.

> Question, what should be done in the case of collisions? 
> Which definition wins, the new library or the existing declaration?
> Maybe we need an override attribute for the library override="true".
> 
> How do you plan to resolve collisions if autoloading is supported?

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.

Tim