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