Conor MacNeill wrote: > Costin Manolache wrote: >> >> >> 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.
My 'itch' is to have pluggable support for component creation. If nobody -1 the ComponentHelper - then any antlib can be implemented as an optional task. I'll probably be ok with any "official" solution ( if it isn't too complex ), and probably I'll do my own experiments. Having a simple ComponentHelper plugin that uses the XML namespace to load a simple properties descriptor is one reasonable solution. Certainly not the only one. >> 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. My point was that naming conflicts are not the biggest problem we are facing. The only way I know to avoid naming conflicts is to use a namespace. Not using the XML namespace if we do need a namespace ( and inventing our own ) would be a very bad idea IMO. I don't think that the antlib concept will directly increase the number of tasks or the likelyhood of conflicts. Renaming tasks is a very different issue. Renaming existing tasks is yet another issue ( and see no reason for it to happen - I think we agree on this). > 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. How is that different from tomcat shiping a properties file ( and using taskdef resource=... ) ? People and companies are already shipping ant tasks and libs. If we want to use XML namespaces to reduce the chance of conflicts - and this can be optional, so "simple" build files will not have to do it - then the syntax is pretty clear. <project xmlsns:tomcat="...." > <tomcat:deploy ... > I don't see too many choices for that ( the URL of the NS is the only big issue ). Do you see any other option on resolving name conflicts in xml files ? > Let's talk about what the build file looks like and work from there. I think we should agree on some basic issues: 1. If a namespace will be used to resolve conflicts - it will be XML namespace ( i.e. we won't invent our own ). 2. Existing files will not have to change. ( i.e. the default namespace will be used for the core tasks ). 3. If you don't need namespaces, you'll not have to use them. I.e. if you have a simple project and use few libs - you can still use the simpler syntax. The xmlns syntax is well defined - the only issue is the semantics of the URI. Some people have strong opinions on that. My (strong:-) preference is for a URI that does have some semantics - i.e. it can be resolved to a java package. Some form of catalog can resolve this to URLs or something else. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
