Jose Alberto Fernandez wrote: >> From: Wannheden, Knut [mailto:[EMAIL PROTECTED] >> >> > >> > Let's not reinvent the wheel here. >> > >> > The solution for names conflicts is namespaces - not rewriting. >> > >> >> I agree. With the new ProjectHelper2 everything should be in >> place to start >> using namespaces. >> > > I have no problem on allowing people to use namespaces, but I do > have a problem on forcing people to use them just because some others > want to use some fancy XML tool. The buildfile belongs to the > user and s/he should be in charge.
Namespaces are the common solution used to resolve name conflicts. I have a big problem on using some "original" solution like renaming tasks with some prefix. This has nothing to do with "fancy XML tools" ( in fact, very few editors are able to deal nicely with namespaces ). We have a problem - name conflits - and one solution. I like Perl and the "there is more than one way to do things", but in this case we have a standard solution that everyone uses, and it would be very confusing and wrong to force the user to learn a different one. >> This would also allow antlibs to have a DTD or XML Schema >> which could be >> used in XML editors or for validation. >> > > Well ANT's XML is the result of introspection, and we already know > our object model cannot be represented by a simple DTD. I see no way > or reson to enforce 3rd party libraries to define their objects > to be DTD-able. > I am not sure about XMLSchema but my hopes are not too high. I agree with you on this one. XMLSchema is one of the worse things I've seen. However it is possible to associate a DTD/schema with (most) of the ant ( we even have a dtd generator, that works great with emacs, I use the DTD every day ). And some users may choose to create build files with editors using only the subset of ant that is supported by the editor ( i.e. fits the restrictions of the DTD/schema ). >> Also namespaces lets the antlib user specify what prefix to >> use. But it >> doesn't allow two antlibs to use the same prefix in the >> context of the same >> element, which I think is good. >> > > This sounds proper in theory, but in practice lets see: > > 1) Lets assume that we still want to be able to chop ANT jars > between core and different optional jars which have specific > dependencies of diferent packages and such. > 2) Now because they are in different antlibs it would mean I am > forced to use different namespaces for each. Why ? I think most people agreed that using the jar file name as a namespace URI is not the best solution. If we go with the package name ( or other solution where the ns is fixed by the antlib creator ) - you can have the files in multiple jars. For package name - the descriptor will have to be in that package. > 3) So now you have people using 3rd party tasks like antcontrib > without problem and without conflicts, but they would have to > change not just one line (to use the antlib) but every bloddy > use of the tasks just because they are forced to use name spaces. I think you started with wrong assumptions here. There is no need to change anything in the core or optional tasks, you can have an antlib that uses multiple jars ( and most likely antlibs will eventually use some dependency mechanism and have mutliple jars ). > I doubt many people will be fill happy about that, and the backward > compatibility consequences. > >> If you really want you can use short names with namespaces as >> well. Just >> set the default namespace locally. >> > > I have no problem using XML namespaces as long as they are independent > of the antlib and under complete user control (not antlib designer > control). In other words the user should be able to decide if s/he wants > to load the library on some particular namespace or in the default "" > namespace which is the one used by core. The namespace is not under user control - by definition. Read the W3C spec, it is designed to be fixed, stable, durable, etc. And there is no point in the user changing the namespace URI - the ns is the id or name of the library. Regarding use of the core namespace if no name conflicts: +1 > So if I say: > > <antlib location="antcontrib.jar"/> > > I will be able to use: <if/>, <switch/>, etc. But is I do: > > <project xmlns:cont="mylibs"> Again - the URI is not under user control, but under the antlib author control. Just like the "if" and the other task names. Allowing the user to rename tasks would be very wrong and confusing. ( let's rename "<delete>" to "copy", then import few files - and figure out what the build file is actually doing ). > <antlib location="antcontrib.jar" usens="cont"/> > </project> > > then I can use <cont:if/>, <cont:switch/>, etc. Costin > Which means that the default value for the 'usens' attribute is "" which > assumes some implicit namespace definitions like: > > xmlns="ant-namespace" and probably xmlns:ant="ant-namespace" > > which uses as kosher namespaces as possible, I think. > > Jose Alberto
