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 Thu, 05 Sep 2002 23:19:54 GMT

Peter Donald wrote:
> On Thu, 5 Sep 2002 20:08, Wannheden, Knut wrote:
>>I know this topic has been brought up before (e.g. in "Optional tasks"
>>thread of last december [1]), but I still wonder what is the actual plan
>>for the accepted requirement for Ant2.
> 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

no need IMHO.

> * types (aka tasks, datatypes, condtions, etc)


> * property evaluation (ie "${javascript:performMagic()}"

This is already done via interceptors in embed:

> * target names (ie if you depend on foo:bar target will that execute bar 
> target in foo project?)

Yes. This is similar to package names in Java imports, for name clashing.

> * aspects (ie add ant:fail-on-error="true" to all tasks)

Seems cool, but I don't think so, too confusing.

> That is too confusing for me as a developer.

Ok, what I said ;-)

 > I would pity the user who had to
> try and understand a buildfile for that.
>><project xmlns=""
>>         xmlns:my="urn:my-ant-tasks"
>>         default="test">
>> <taskdef qname="my:foo" classname=""/>
>> <taskdef name="baz" ns="urn:my-ant-tasks" classname=""/>
>> <target name="test">
>>  <echo message="test"/>
>>  <my:foo/>
>>  <whatever:baz xmlns:whatever="urn:my-ant-tasks"/>
>> </target>
>>(Note the two different uses of <taskdef>.)
> type aliasing is no problem but I think that is independent of the main issue.


> However I think you will find it hard pressed to validate anything without the 
> runtime context being present. It may be possible but I think that it would 
> need to be seen to be believed ;)


Costin has avoided using the namespace effectively till now because of 
what you say; personally I find jelly a bit confusing because of these 

I think that, apart from the virtual namespace in property evaluations, 
the only need I see of namespaces is in imports of other projects, for 
identifying the tasks-targets-properties? that can have different names.

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