But we have namespace support now ! :-)
You mean XML namespace support? That is (potentially) different from the task/type namespace. Perhaps XML namespace can be used for task resolution. It has been mooted in the past for other roles (identification of aspects, such as a documentation aspect). We probably need some agreement on how/if to use XML namespaces in Ant.
And naming collision was allwasy a possiblity with taskdef.
Indeed. Every time we change defaults.properties we can cause people to have to rewrite their build files to avoid the collision. It may even break existing build files, I'm not sure. This problem is much smaller than the problem that will exist when we provide an Antlib concept. IOW, I don't think we can argue that the pre-existence of a problem allows us to neglect that problem in the future.
When we have antlibs, I expect people and companies to start shipping antlibs. Let's say, for example, that tomcat and an app server provider both ship antlibs and both provide a <deploy> task. How can I use those tasks? If you believe this can be supported through XML namespaces, we need to work out what the build file looks like for that, I think.
Further I believe build files should make explicit the libraries/tasks they depend on. IMHO, we don't want to tie a build file's operation to the
That's a very good poing, I agree. That's why I think using the ns is a good idea.
So, for me two requirements for antlib 1. Global management of task names, handling name collisions, name resolution, aliasing, etc.
I'm not sure I understand what you mean - or if NS would cover your requirement.
Let's talk about what the build file looks like and work from there.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
