ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: xml namespace support in ant2
Date Mon, 30 Sep 2002 20:10:54 GMT
Dominique Devienne wrote:

> 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?

Well, I did write about this several times in the past. I don't have
any formal proposal and no code to check in yet ( except for a hook that
I'm still testing ).

> 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.

There is no chunk of code - all I have as code is a single class with a 
single method ( and 2-3 lines of changes in ProjectHelper to call the 

> 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.

For imports - my proposal is in proposal/embed. It has been discussed a lot,
and I think this piece is ready for majority vote ( and I'll do that 
soon ). The 'dynamic properties' are stable, but I still want to try 
other languages and BSF. 

For antlibs - I just want to propose a hook ( ProjectComponentFactory )
to be called by RuntimeConfigurable/UnknownElement/ProjectHelper before
calling the default method. That will allow diferent user-defined task
factories to be defined.

I'm also working on a particular factory, using commons-discovery and
a simple properties file - but I don't plan to propose it soon, it's
just experimental code to test some ideas.

For each 'feature' I plan to propose a separate majority vote for the
API ( or behavior ) and a separate vote for the implementation ( which
may be the one in embed or modifications on the existing ProjectHelper ).
In case a feature is rejected, I plan to do the same thing as ant-contrib -
i.e. treat the feature as a separate add-on.

I don't see anything wrong with this aproach - all of the features I'm 
interested on have been discussed ( or at least I posted my intentions
and requests for comments - see thy 'my itches' thread ). While embed 
is becoming a 'large chunk' and includes a lot of features, each
feature is relatively independent of the others.


> 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
> To:
> 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  ).
> Costin
> 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: <>

View raw message