> > >
> > > Let's not reinvent the wheel here.
> > >
> > > The solution for names conflicts is namespaces - not rewriting.
> > >
> >
> > I agree. With the new ProjectHelper2 everything should be in
> > place to start
> > using namespaces.
> >
>
> 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.
> > This would also allow antlibs to have a DTD or XML Schema
> > which could be
> > used in XML editors or for validation.
> >
>
> Well ANT's XML is the result of introspection, and we already know
> our object model cannot be represented by a simple DTD. I see no way
> or reson to enforce 3rd party libraries to define their objects
> to be DTD-able.
> I am not sure about XMLSchema but my hopes are not too high.
>
With roles I think XML Schema could very well be used to validate a
buildfile. But I'm not saying that a schema should be enforce. It would be
a gain of using XML namespaces.
> > 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.
I suppose it would also be possible to let one antlib extend another one,
thus letting it use the same namespace.
> 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/>.
> > 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>
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.
> 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?
--
knut
