Return-Path: 
 <ant-dev-return-18230-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 40943 invoked by uid 500); 9 Oct 2001 11:56:57 -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 40931 invoked from network); 9 Oct 2001 11:56:57 -0000
Message-ID: <00d001c150b9$27705690$0100a8c0@jose>
From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
To: <ant-dev@jakarta.apache.org>,
	<tneward@javageeks.com>
References: <HGEEIKOHHDJKIOMBLAAEKEBOEEAA.tneward@javageeks.com>
Subject: Re: Optional tasks
Date: Tue, 9 Oct 2001 12:54:27 +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

XML Namespaces have been suggested as part of Ant2, however I think the =
discussion has concentrated on what would be the best way to use then =
which is simple and effective.

To me the only good reason to have namespaces is to be able to use in =
the same project tasks from different sources that may be using the same =
names. In current Ant this is not possible since the name space is flat. =
For the use of libraries, we do not really require namespaces but just a =
way to import (as Donald mentioned already) the task belonging to a =
particular library.

I also prefer the manual declaration of the libraries being used as =
opposed to some auto-install sort of facility. The reason for this is my =
believe that is much better to document in the buildfile which resources =
are required than to assume that every user will find out by other =
means.=20

Once you accept this there is no reason to enforce that libraries are =
located in some especific place, they can be anywhere including a remote =
location. ANT may provide a convinient location (${ant.lib}) but it =
should be just that a convinience.

The next question is how this libraries interact with ClassLoaders. =
Should each library have its own ClassLoader? Should they be able to =
share them? How about external libraries being required? Shall one be =
able to specify an additional ClassPath for the library?

<tasklib name=3D"lib1" location=3D"mydir/mytasks.jar" />

  <lib1:mytask .... />

<tasklib location=3D"${ant.lib}/optional.jar">
    <classpath path=3D"${ant.lib}/junit.jar" />
</tasklib>

    <junit ..... />

This would allow a way to provide namespace support and otherwise =
simplifying things.

Now with all that many view from each one of us, no wonder we haven't =
really settle on one yet.

Jose Alberto

----- Original Message -----=20
From: "Ted Neward" <tneward@javageeks.com>
To: <ant-dev@jakarta.apache.org>
Sent: Tuesday, October 09, 2001 6:57 AM
Subject: RE: Optional tasks


> What about some kind of idea similar to XML namespaces?
>=20
> MyTasks.jar
> -----------
> contains com.develop.MyCustomAntTask
> and the manifest holds
>=20
> Manifest-Version: 1.0
> Ant-Task-Namespace: urn:developmentor.anttasks.v1
> Ant-Task: mytaskdef com.develop.MyCustomAntTask
>=20
> (or maybe this needs to be a "task descriptor" buried somewhere inside =
the
> .jar file; either way, the idea is the same)
>=20
>=20
> In my build.xml file I write
>=20
> <ant:project xmlns:ant=3D"http://jakarta.apache.org/Ant/v2"
>              xmlns:mytasks=3D"urn:developmentor.anttasks.v1">
>=20
> <mytasks:mytaskdef attr1=3D"foo" attr2=3D"bar" />
>=20
> </ant:project>
>=20
>=20
> When Ant starts up, it'd scan the .jar files in the "tasklib" =
directory,
> establish the namespace-per-tasklib mapping, and then use the XML
> namespaces-to-prefixes syntax to allow the author of the build script =
to use
> whatever prefix is desired. Very similar to how JSP taglibs work.
>=20
> Just a random thought out of the blue.
>=20
> Ted Neward
> {.NET||Java} Course Author & Instructor
> DevelopMentor (http://www.develop.com)
> http://www.javageeks.com/tneward/index.html
>=20
> > -----Original Message-----
> > From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> > Sent: Friday, October 05, 2001 4:52 AM
> > To: ant-dev@jakarta.apache.org
> > Subject: Re: Optional tasks
> >
> >
> > Kevin Jones wrote:
> >
> > > How does ant 'know' about the optional tasks? Are they defined
> > as part of
> > > the Ant core?
> > >
> > > For example if I use the JUnit task Ant picks the taskdef directly =
from
> > > options.jar (or whatever this releases jar file is called. But
> > if I create
> > > my own task I have to put a taskdef in my build.xml file, even
> > if I put the
> > > jar file containing the task into ant\lib. I was wondering where =
the
> > > optional task magic comes from?
> > >
> >
> >
> > Kevin, there isn't much magic. All of the optional tasks that come =
with
> > Ant are defined in the default.properties resource within Ant, along
> > with the core tasks. The distinction between a core and an optional =
task
> > is somewhat fuzzy. In general a core task requires no additional
> > resources beyond those provided by the JDK and Ant itself. Optional
> > tasks usually require something more, that some Ant users may not =
have
> > installed. It maybe a third party library (jar) such as JUnit or it
> > could be something from the javax namespace. Further, IMHO, core =
tasks
> > are somewhat more fundamental in some way. Optional tasks are
> > effectively taskdef'd for you, but without the opportunity to =
specify
> > the classpath, etc. They are required to be on the classpath, which =
the
> > optional.jar normally is.
> >
> > Overall the mechanism is rather unsatisfactory and we have long
> > considered a different approach of task libraries which when you =
drop
> > them into your ANT_HOME/lib area would automatically make the tasks
> > available, subject to some mechanism to handle ambiguous tasknames.
> >
> > Conor
> >
> >
> >
> >
> >
> >
> >
>=20