ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: Namespaces in Ant
Date Sun, 04 May 2003 07:35:25 GMT
> Costin Manolache wrote, On 03/05/2003 8.22:
> ...
> > One use case I had in mind for CH was a namespace like "jmx:...", 
> > where the JMXComponentHelper would use the JMX metadata to 
> create the
> > task ( no ant table ). That's clearly outside the scope of 
> antlib or ant (
> > it's just a custom task ).
> This seems interestig, and brings up what XML namespaces can 
> be used for.
> It has been said that they can be used to separate the tasks/types 
> loaded by different antlibs. But yesterday I was thinking of 
> Java, and 
> how import works... and I imagined having to write the full 
> namespaces 
> except for the Java one, as would happen in Ant with XML 
> namespaces... 
> ugh :-P

Many buildfiles would still only use what's delivered as part of the Ant
distribution.  And for backwards compatibility (and succinctness) reasons
all these tasks and types will be in the default namespace.  So you'd only
ever use namespaces where you use custom tasks and types.

Also the namespace provides a way to talk about the antlib itself in the
buildfile.  Don't know what that currently would be used for, but maybe
someone wants to be able to unload an antlib from the Project again.  Of
course also id and idref attributes could be used for this purpose.

A big difference between the Java and Ant buildfile model is of course also
that in Java you usually use a compiler which is there to inform you what
needs to be disambiguated before it can be compiled, whereas in Ant you only
have the runtime.

I remember that the PropertyHelper supports some kind of namespace syntax (a
prefix followed by a ':' and a string expression) to enable different
property processing.  I was wondering if it would be a good idea to link
these namespaces to the namespaces used for the antlibs.  This way antlibs
could declare a PropertyHelper class which could be loaded.  But only one of


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message