> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>
> > I have no problem on allowing people to use namespaces, but I do
> > have a problem on forcing people to use them just because
> some others
> > want to use some fancy XML tool. The buildfile belongs to the
> > user and s/he should be in charge.
> >
>
> As someone already said, it's about "not reinventing the
> wheel", not about
> enabling the use of fancy tools. But as ubiquitous and
> accepted as XML
> namespaces are, I see many things that could be gained from using
> namespaces. Also, I suspect most users familiar with XML
> will have had some
> dose of contact with namespaces.
>
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
> > > use. But it
> > > doesn't allow two antlibs to use the same prefix in the
> > > context of the same
> > > element, which I think is good.
> > >
> >
> > This sounds proper in theory, but in practice lets see:
> >
> > 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.
> >
> > 2) Now because they are in different antlibs it would mean I am
> > forced to use different namespaces for each.
> >
>
> Is that really so? As I understood it antlibs wouldn't be a
> requirement for
> providing Ant tasks and types. I thought the normal <taskdef/> and
> <typedef/> would still work as they do now.
>
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
> another one,
> thus letting it use the same namespace.
>
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
> name spaces.
> >
>
> To use antcontrib as an antlib they would at the very least
> have to replace
> the <taskdef/>s with an <antlib/> element or something, no?
> But the tasks
> should still work as they do now using <taskdef/>.
>
So not the antlib writer will have to provide both an XML descriptor
AND a properties file? How about all the fancy typing?
> > > If you really want you can use short names with namespaces as
> > > well. Just
> > > set the default namespace locally.
> > >
> >
> > I have no problem using XML namespaces as long as they are
> independent
> > of the antlib and under complete user control (not antlib
> > designer control).
> > In other words the user should be able to decide if s/he
> wants to load
> > the library on some particular namespace or in the default ""
> > namespace
> > which is the one used by core.
> >
> > So if I say:
> >
> > <antlib location="antcontrib.jar"/>
> >
> > I will be able to use: <if/>, <switch/>, etc. But is I do:
> >
> > <project xmlns:cont="mylibs">
> > <antlib location="antcontrib.jar" usens="cont"/>
> >
> > </project>
> >
> > then I can use <cont:if/>, <cont:switch/>, etc.
> >
>
> I think the <antlib/> shouldn't define the prefix, but the
> namespace URI
> instead . Something like:
>
> <project xmlns:cont="urn:uri-supplied-by-ant-user">
> <antlib location="antcontrib.jar"
> ns="urn:uri-supplied-by-ant-user"/>
> <cont:if/>
> </project>
>
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="".
> Of course if the antlib would provide its own namespace in
> the descriptor.
> Ant could do some kind of automatic loading when a namespace
> declaration
> matching the namespace URI is encountered. But I'm not sure
> that's a good
> idea.
>
Agreed it is not good idea.
> > Which means that the default value for the 'usens' attribute
> > is "" which assumes
> > some implicit namespace definitions like:
> >
> > xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"
> >
> > which uses as kosher namespaces as possible, I think.
> >
>
> But this would require that the <project/> element would
> define the default
> namespace like this:
>
> <project xmlns="ant-namespace">
> ...
> </project>
>
> Why not use the empty namespace for Ant core?
>
Fine with me.
Jose Alberto
