ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: xml namespace support in ant2
Date Fri, 06 Sep 2002 21:54:14 GMT

J.Pietschmann wrote:
> Peter Donald wrote:
>> I don't think there is any plan for it at this stage. There are too 
>> many potential uses of namespaces and associated confusion. Do you 
>> namespace;
>> * property names
>> * types (aka tasks, datatypes, condtions, etc)
>> * property evaluation (ie "${javascript:performMagic()}"
>> * target names (ie if you depend on foo:bar target will that execute 
>> bar target in foo project?)
>> * aspects (ie add ant:fail-on-error="true" to all tasks)
> There are existing XML related specs using namespace. Perhaps
> part of Ant's usage can be modeled after XSLT:
> - Core: All elements defined by the Ant core specification are
>   in the Ant namespace.

+1 I just patched my local version to accept a default namespace.

> - Top level: Elements which are immediate children of the
>  document element ant:project and which are not in the
>   Ant namespace must be namespace qualified and in some other
>   namespace. If the processor doesn't know how to handle such an
>   element, it is silently ignored.
>   In XSLT, such elements are used for putting arbitrary data
>   and documentation into the file:
>   <ant:project xmlns:ant=""
>     xmlns:doc="">
>    <doc:propdoc>
>      <p>The property <propname/> is set if the XYZ class
>      is available on the classpath</p>
>    </doc:propdoc>
>    <ant:property name="" .../>

But we can have top-level tasks...

NOTE: Since an element that is a child of an Ant Project element is not 
occurring in a target, non-Ant top-level elements are not extension 
elements as defined here, and nothing in this section applies to them.


> - Extension elements: All other elements which are not in the Ant
>   namespace must be in some other namespace, and it is an error if
>   the processor does not know how to handle them unless they are
>   in an ant:fallback element (or something similar)
> (see for details)

Which means that if they are not top-level and have a namespace that is 
not ant's and ant doesn't know how to handle them, it's an error.

But (changed to us Ant terminology):

If Ant does not have an implementation of a particular extension element 
available, then the element-available function must return false for the 
name of the element. When such an extension element is instantiated, 
then the Ant processor must perform fallback for the element as 
specified in [15 Fallback]. An Ant processor must not signal an error 
merely because a target contains an extension element for which no 
implementation is available.

Here it's clear that XSLT extensions rely on the fact that there are 
templates to structure everything, and there are no top-level things; 
Ant is a bit different...

So instead we could say that
1) all ant: namespace elements are core ant.

2) different namespaced elements have to be defined before use as 
taskdefs, typedefs or antlibs, and ant treats them accordingly

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 

> I'd also suggest to introduce a version attribute on the
> project element, just in case.


> I'd also advice against using namespaces (more precisely: QNames)
> for target and property names, see below.

Currently they are used only when reqesting a property in ${}, and it 
may be really confusing to have them also in the names, I tend to agree.

On the other hand I can have clashes of names, but it can also be a 
"feature", and not a problem that cannot be resolved with good naming rules.

> As for target name scopes which become relevant for imports I'd
> use the import tree approach roughly like XSLT does: the import
> tree is traversed until a target is found, the subtree of this
> node is skipped and the tree is traversed further, if there is
> a second match, an error is thrown.
> This means the following is ok, because X in B is "shadowed"
>   main
>     importA
>        importB
>          target X
>        target X
> while this is an error (if the imported X is invoked)
>   main
>     importA
>        target X
>     importB
>        target X

Sorry, I don't understand, can you please explain it with an Ant 
example? Thanks.

> Kludges like "super.X" should be avoided, partly because "super"
> is hard to define both intuitively and reasonably contradiction-free,
> partly for possibly clashes with a user defined target which happens
> to have the name "super.X", and also for other reasons.

In the embed proposal it has be superceded by prepending the name of the 
original project name.

But super.x can enable you to automatically collect features:

project1.a (inside it calls super.a)
project2.a (inside it calls super.a)
project3.a (inside it calls super.a)

If I import these three, I can have a resulting a that calls all three, 
since the import has collected all of them because each of them asked to 
be attached to the previous one.

Do you have suggestions on how to implement this in another way?

> As for using namespaces for scoping targets: the role of namespaces
> is to avoid name clashes for XML *elements*, therefore encouraging
> aggregation of XML from various vocabularies and fostering reuse
> of existing vocabularies. The scope for targets are projects, not
> XML vocabularies. Same goes for property names.

Hmmm... so tasks should have namespaces, targets and properties cannot, 
since they are not elements.
I tend to agree.

> From time to time I ponder to write a complete specification for
> Ant build files and perhaps a proper processing model, unfortunately,
> this is quite time consuming and motivation is low...

We're slowly getting there anyway ;-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message