ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: xml namespace support in ant2
Date Mon, 30 Sep 2002 18:56:02 GMT
Frankly, this sounds great Costin. But, from what you are writing below, it
sounds that you have thought a lot on the issue of antlibs and use of
namespaces in Ant, yet I haven't read anything about this prior to this
particular message... Did I miss the discussions on it?

I'm afraid that once more a big chunk of good code will get vetoed because
not thoroughly discussed by the community before-hand, and not easily
digestible by pieces. Sure, having something already implemented that works
is a great base for discussions, but looking back at what happened not too
long ago with the Ant2 proposals, maybe it isn't enough after all.

In summary, I'd like to be able to hear more from you about how you want to
tackle antlibs, imports, etc... so that maybe I get my views / use cases in
from the users perspective, and also (and maybe foremost) so that some kind
of consensus agrees it's the right direction.

But maybe I'm just ignorant of how Open Source project work again... --DD

-----Original Message-----
From: Costin Manolache [] 
Sent: Monday, September 30, 2002 12:33 PM
Subject: RE: xml namespace support in ant2

My opinion:

1. I hate using schema for validation. XML is not the only way to use
ant - there are already projects using ant tasks as beans, and it's a good
code reuse. 
Besides, schema is still slow ( and will allways be - due to it's 
complexity). Even Relax or simpler schemas can't ever beat the if()
in the task, which also cover the use of the beans.

2. However schemas are good for documenting the task and for possible
tools. As long as we don't use them for validation ( which I'll -1 as strong
as I can ).

3. The embed proposal uses SAX2, but it is not doing anything ( yet ) with 
the namespaces. My original plan was ( and still is ) to use the namespace
as an ID, and use it to locate the task definition using getResource().
For a task in NS, I would look up META-INF/ant/encoded(NS)/SOMETHING - and 
locate the description of the tasks in that namespace and additional 
metadata. The descriptor should support both properties (for simple cases)
and an XML form. 

4. A very tricky issue is the syntax of the ID. We can use a meaning-less
string, or a URL that can be used to download the lib. Even in the first 
case ( arbitrary string ) we can have a 'antlib registry' - but it would 
be extra overhead. I know there are many (strong) opinions on this.

5. Even if ns is added, most people will still prefer to use the default
namespace. It's just much easier to type and use ( at least IMO - and from
what I've seen ). Should we restrict the default ns to ant core tasks and
force everyone to use ns for extensions ? I don't think so.  

6. Namespaces should be used instead of 'taskdef' whenever possible 
( i.e. the descriptor  ).


Wannheden, Knut wrote:

> This reply is a little bit late (just got back from holiday) but I think
> it's an important topic and I was wondering if anybody has given this more
> thought in the meantime.
> With some minor adaptions I think your general description of the usage of
> XML namespaces sounds very good.
>> -----Original Message-----
>> From: Nicola Ken Barozzi []
>> Sent: Freitag, 6. September 2002 23:54
>> To: Ant Developers List
>> Subject: Re: xml namespace support in ant2
>> So instead we could say that
>> 1) all ant: namespace elements are core ant.
> Well, what the namespace prefix is in the buildfile is really up to the
> user.  It's just the URI that matters.  So all of thw following should
> work:
> <project xmlns="urn:ant-namespace">
>  <target name="test"/>
> </project>
> <xyz:project xmlns:xyz="urn:ant-namespace"/>
> But specifying it as the default namespace as in the first example or
> using "ant" as the prefix will probably be the most common usages.
> When you say "core ant" I assume you're talking about <project>, <target>,
> all core and optional tasks and types in the distribution.
>> 2) different namespaced elements have to be defined before use as
>> taskdefs, typedefs or antlibs, and ant treats them accordingly
> I think saying it the other way around would be more correct.  I.e. Custom
> tasks and types have to be declared to use a different XML namespace.
>> 3) all namespaced tags that are not declared as in (2) must
>> be declared
>> beforehand as <namespacedef namespace="nms" handler="..."/>,
>> so that the
>> Ant ProjectHelper can use that particular Handler to process the
>> extension. A convenient nullHandler is created when the
>> handler is not
>> specified.
> What would this be used for?  Isn't it enough with task and type
> extenstions?  Other extensions would certainly raise confusion...
> The primary benefits I see of using XML namespaces the described way are:
> - Mechanism to avoid name clashes of different tasks and types
> - Schemas (grammars) could be written for Ant buildfiles covering the Ant
> core elements and external tasks and types.
> The schemas in turn would allow the validation of tasks and types to take
> place externally and at an earlier stage.  With externally I mean that the
> tasks and types wouldn't need code to do the validation themselves.
> At a later stage the schemas could maybe even be the basis for the
> documentation.  Also, the different usages of a task could maybe be bound
> to the different processing modes somehow.
> Playing some with RELAX NG and Sun's MSV validator I found that it was
> quite
> easy to specify grammars for the different Ant tasks and types.  Even
> writing grammars that support other namespaces isn't very hard.  That way
> a grammar which validates buildfiles using other namespaces for external
> tasks
> and types can be constructed easily.  It should also be quite easy to
> allow external tasks to specify their own grammar for validation.
> Any thoughts?
> Cheers,
> --
> knut


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message