ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Antlib... when?
Date Mon, 06 Jan 2003 15:36:16 GMT
Wannheden, Knut wrote:

>> 2. Existing files will not have to change. ( i.e. the default
>> namespace
>> will be used for the core tasks ).
> Wouldn't it be a good idea to introduce a namespace for the core tasks and
> make the default namespace deprecated.  

Good idea for what ? 

You should be able to use a namespace with the core ( you can already - 
since ns is ignored :-). But I don't think requiring namespaces would be 
a good idea. Just keep simple things simple.

> <project xmlns="antlib:org.apache.ant.core">
>  <.../>
> </project>
> The only difference would be that <project/> would declare the default
> namespace.

The only difference is that people will have more to type and the build
file will get more complicated. 

> A question:  How should namespaces and nested elements be handled?  Let's
> say I write my own antlib (package with a task <bar/>.  Then my
> buildfile would contain something like:
>     <antlib name=""/>
>     <foo:bar xmlns:foo=""/>

ProjectHelper will set the namespace in each UnknownElement. ComponentHelper
will construct each element based on name and namespace. It doesn't matter
where the ns is declared - that's an XML detail.

> If I now want to extend the task to use nested elements, in what namespace
> would they be and how would this affect the setXXX() interface of the
> task? I suppose the options are to use the default namespace or the same
> namespace
> as the task.  So either:
>     <foo:bar xmlns:foo="">
>       <baz/>
>     </foo:bar>
> or:
>     <foo:bar xmlns:foo="">
>       <foo:baz/>
>     </foo:bar>


Are you trying to give one example of why adding complexity is bad, and
why we should avoid using namespaces ??

AFAIK the patterns for creating childs are using only the name of the
task - so both will work. We could extend IntrospectionHelper to use ns,
but I really don't see any benefit to justify the complexity.

> I suppose the second choice would be nice to have because then it would be
> quite clear what is meant by a nested <fileset/> element (which is
> declared in the core antlib).


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

View raw message