Return-Path: <jalberto@cellectivity.com>
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 93156 invoked from network); 7 May 2003 23:40:05 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 7 May 2003 23:40:05 -0000
Subject: RE: Roles (was: antlib)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2003 00:40:11 +0100
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F50F5@london.cellectivity.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Roles (was: antlib)
Thread-Index: AcMUmAvVUm6eCcwYQy+bF1zpJ4buBAAV2E6A
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Wannheden, Knut [mailto:knut.wannheden@paranor.ch]
>=20
> > I have no problem on allowing people to use namespaces, but I do=20
> > have a problem on forcing people to use them just because=20
> some others
> > want to use some fancy XML tool. The buildfile belongs to the
> > user and s/he should be in charge.
> >=20
>=20
> As someone already said, it's about "not reinventing the=20
> wheel", not about
> enabling the use of fancy tools.  But as ubiquitous and=20
> accepted as XML
> namespaces are, I see many things that could be gained from using
> namespaces.  Also, I suspect most users familiar with XML=20
> will have had some
> dose of contact with namespaces.
>=20

But ANT is not for experience XML users but for Java programmers
or C or .NET (with the new tasks). ANT is popular because
it is simple to use you do not have construccions that require
you to read a full spec to understand. I am not against NS, but
I am against forcing people to use them just because.

> > > Also namespaces lets the antlib user specify what prefix to=20
> > > use.  But it
> > > doesn't allow two antlibs to use the same prefix in the=20
> > > context of the same
> > > element, which I think is good.
> > >=20
> >=20
> > This sounds proper in theory, but in practice lets see:
> >=20
> >  1) Lets assume that we still want to be able to chop ANT jars
> >     between core and different optional jars which have specific
> >     dependencies of diferent packages and such.
> >=20
> >  2) Now because they are in different antlibs it would mean I am
> >     forced to use different namespaces for each.
> >=20
>=20
> Is that really so?  As I understood it antlibs wouldn't be a=20
> requirement for
> providing Ant tasks and types.  I thought the normal <taskdef/> and
> <typedef/> would still work as they do now.
>=20

So again you have a two tier world where some things are more core
than others. Me as a library provider need to decide now whether
to ship my library with a property file so that it can be incorporated
seemingly into ANT namespace or use an XML definition and force
my users to learn NS. Hummmm

> I suppose it would also be possible to let one antlib extend=20
> another one,
> thus letting it use the same namespace.
>=20

The suggestion I was critisazing was that of having "one ANTlib one URI"


> >  3) So now you have people using 3rd party tasks like antcontrib
> >     without problem and without conflicts, but they would have to
> >     change not just one line (to use the antlib) but every bloddy
> >     use of the tasks just because they are forced to use=20
> name spaces.
> >=20
>=20
> To use antcontrib as an antlib they would at the very least=20
> have to replace
> the <taskdef/>s with an <antlib/> element or something, no? =20
> But the tasks
> should still work as they do now using <taskdef/>.
>=20

So not the antlib writer will have to provide both an XML descriptor=20
AND a properties file? How about all the fancy typing?

> > > If you really want you can use short names with namespaces as=20
> > > well.  Just
> > > set the default namespace locally.
> > >=20
> >=20
> > I have no problem using XML namespaces as long as they are=20
> independent
> > of the antlib and under complete user control (not antlib=20
> > designer control).
> > In other words the user should be able to decide if s/he=20
> wants to load
> > the library on some particular namespace or in the default ""=20
> > namespace
> > which is the one used by core.
> >=20
> > So if I say:
> >=20
> > 	<antlib location=3D"antcontrib.jar"/>
> >=20
> > I will be able to use: <if/>, <switch/>, etc. But is I do:
> >=20
> > 	<project xmlns:cont=3D"mylibs">
> > 	   <antlib location=3D"antcontrib.jar" usens=3D"cont"/>
> >=20
> > 	</project>
> >=20
> > then I can use <cont:if/>, <cont:switch/>, etc.
> >=20
>=20
> I think the <antlib/> shouldn't define the prefix, but the=20
> namespace URI
> instead .  Something like:
>=20
> 	<project xmlns:cont=3D"urn:uri-supplied-by-ant-user">
> 	   <antlib location=3D"antcontrib.jar"
> ns=3D"urn:uri-supplied-by-ant-user"/>
>          <cont:if/>
> 	</project>
>=20

I thing this is what I meant (in escense), with the understanding
that:

	a) the user can use the same URI on several <antlib>s
	   (any conflicts are his problem)

	b) the default value for the ns attribute is ns=3D"".

> Of course if the antlib would provide its own namespace in=20
> the descriptor.
> Ant could do some kind of automatic loading when a namespace=20
> declaration
> matching the namespace URI is encountered.  But I'm not sure=20
> that's a good
> idea.
>=20

Agreed it is not good idea.

> > Which means that the default value for the 'usens' attribute=20
> > is "" which assumes
> > some implicit namespace definitions like:
> >=20
> > 	xmlns=3D"ant-namespace" and probably xmlns:ant=3D"ant-namespace"
> >=20
> > which uses as kosher namespaces as possible, I think.
> >=20
>=20
> But this would require that the <project/> element would=20
> define the default
> namespace like this:
>=20
> 	<project xmlns=3D"ant-namespace">
> 		...
> 	</project>
>=20
> Why not use the empty namespace for Ant core?
>=20

Fine with me.

Jose Alberto