> From: Costin Manolache [mailto:[EMAIL PROTECTED] > > > 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 ). > >
So you want to continue with the aberration of allowing having tasks in the descriptor that cannot be loaded or fail to resolve due to lack of dependencies? This is what we have to allow today in order to have those magic property files that contain all the optional tasks. At least I was striding to get rid of it. But if you impose the rule "one antlib one URI" (as it was suggested) then you have to continue with this aberration just for backward compatibility. Let me just make clear that I am assuming the content of an "antlib" is defined by its XML (or whatever) descriptor. > > 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. > There is definetly nothing on W3C about antlib libraries. The URI is just a string and W3C imposes no meaning to it. Whether it is universally unique or not is just suggested not impossed, the same as public-ids for DTDs. As long as you can distinguish between two diferent things that is all that is required. > Regarding use of the core namespace if no name conflicts: +1 > So I am an <antlib> writer and have a <shitch/> task and because it does not conflict with core I fix it in the core namespace. So ANT 1.7 comes along and decides to add a <switch/> task to core. Now what, did 1.7 broke backward compatibility? My antlib is now incompatible with the new version of ANT eventhough no APIs where mofified. Is ant.apache.org gonna monitor all 3rd party <antlibs> to make sure core never uses a name someone else already used? This is a administration nightmare. This is why I am saying let the user resolve the conflicts, if he decides to use two antlibs with clashes, then allow him to load them is separate namespaces to resolve its own conflicts. > > > > 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 ). > Tell me where in the introspection engine this is required. This is just your idea. Antlib could pick the namespace dynamically at loading time. And lets just say that today I could rename all tasks to french names if I wanted just need to write a properties file. (granted the inner-elements will continue in english, but hey). Jose Alberto
