peter reilly wrote: > I would agree with XML namespace usage like this. > There are however some major and minor consequences > - in no particular order. > > 1) the code to handle XML namespaces in ProjectHelper2 is > not yet complete. > - namespaces of attributes is not handled yet - the > code uses getQName() on the attributes and does > not pass the URI of the attributes to the attribute list given > to
Easy to fix it to localname, but I don't want to get into ns + attributes, let's leave it for ant1.7 :-) ( or at least wait for the component creation to be done ). Attribute + NS affects the introspection. > - the uris for project/target elements/attributes are not checked. Project and target are "owned" by ant, you can't redefine them in antlibs. > - the ns standard allows different types of software processing > for the different namespaces, if this is to be supported > ProjectHelper2 would need to look at the uri before handing the > element to the "ElementHandler" object (see my previous e-mail > on the subject) Not sure I agree ( or understand ) this. What's missing is UnknownElement ( which actually creates the component ) passing the NS to ComponentHelper. Instead it calls the old Project.createTask, etc. That's easy to fix. ProjectHelper2 doesn't care about namespaces or element names ( except project/target ) - it just passes them to UnknownElement. > 2) The usage of Project#createTask/DataType(name) will not work for > tasks loaded as a result of XML namespaces, a > Project#createTask/DataType( uri, name) method will need to be added. +1 The real problem here is changing the code that _calls_ createTask(name) to use the 2 param. That would make the code specific to ant1.6 An alternative would be to also change createTask( String ) to look for a ":" in the name, and if found to separate the last part as name, the first part as URI. For most current uses ( createTask with core tasks ) things will continue to work since ant has the default namespace. > 3) In what ns will the introspected attributes and nested elements of the > new > elements reside? Some of the previous e-mails assume that they belong > in the antlib's namespace - but what about datatypes that extend ant's > datatypes - e.g mypath. (This is assuming that the attributes/nested > elements are found by introspection - for jmx:... this may not be the > case - or a different Class than IntrospectionHelper may be used). Those created by IntrospectionUtil - it doesn't matter, it's set by the introspection rules. For the new polymorphic tasks - probably the same rules of component creation as in top-level tasks. ( still not sure if we agreed on how many lookup tables we'll use ) > 4) the proposed polymorphic element type substitution > <element type="newtype"/> will need to be made ns-aware. either > <newtype for-element="element"/> or the ns prefix -> ns uri mapping at > the parse time when processing type="newtype" will need to be > maintained. Probably using the prefix in newtype would be the most intuitive ( <element type="antcontrib:if" /> ), but that will require some tricky change in PH2 to implement. It is easier to do <antcontrib:element type="if" />, but that's ugly. I don't think this is a showstopper. > 5) Use of the ns form <project xmlns:myxyz="ant:net.sf.antcontrib/> means > that > there is no need for antlibs. Indeed having them would be confusing. > To mis-quote the perl mantra, there should be only one way to do > things. There is no "lib", just a definition file in the classpath. What do you mean ? An antlib is a jar with a descriptor and a URI ( either a package name - or something else ). ( the use of package is just one proposal ) The autodiscovery remains an open issue - it can be done by scanning the jars for the descriptor, or using META-INF ( the other proposal ). Note that even if the NS==package, the descriptor doesn't have to reside in the package, it can be in META-INF. I think both options have some benefits, we need to choose one. It is possible to have the descriptor in the package and also use META-INF/Manifest to list the descriptors > 6) The current usage of <typedef resource="..."/> will still > be maintained. One of the ideas floating about in discussion for > antlib is that one can have <typedef name=.. classname=... > adaptor=.."/>. To allow third party add-ons to do this without using > ns or antlibs, one would need to load the xml definition file with > for example <typedef resource="net/sf/antcontrib/antdefintions.xml"/> > or <typedef defresource="net/sf/antcontrib/../"> or provide a new > task to process the definition file/resource. It needs to be maintained at least for backward compat. And one proposal is to use <typedef> elements in the antlib descriptor. Having the adaptor attribute would be great ! > To support this I would propose the following: > > 1: define the xml format of the definition file. > I would propose a root element of "antdef" and nested elements of > "typedef" and "taskdef" and a possible "description" nested element > and/or attribute. Or "antlib" as root element ? I'm pretty sure sooner or later we'll have some "conditions" or "echo" or even paths :-) And also "dependencies" in one form or another. But for start <typedef> should be enough. I wouldn't use <taskdef> - just a typedef and the fact that implements Task or has an adapter that implements task > 2: either extend the <typedef/> task to use the definition file in the > same way as property files are deal with at the moment or provide > a task - <antdef [resource="..." | file ="..."] [classpath attributes > and nested elements from typedef/> Again - <antlib ... > :-) > 3: release/document the <classloader/> task to manipulate the classpath. Sorry - tomcat took much more than I expected last weekend. > 4: Implement the XML ns changes to use the xml definition file possibly > using a predefined filename and using a package name. Not sure I understand - which part are you talking about ? Costin > > Peter > > On Wednesday 07 May 2003 06:14, Costin Manolache wrote: >> Let's not reinvent the wheel here. >> >> The solution for names conflicts is namespaces - not rewriting. >> >> If we use a prefix, let's stick with what everyone else is using. >> Inventing some "original" solution ( that may or may not be easier or >> more flexible than the W3C solution ) won't make things better for the >> user. >> >> <antlib location="antcontrib.jar" prefix="myxyz-" /> >> <myxyx-if ...> >> >> is not easier than >> >> <project xmlns:myxyz="ant:net.sf.antcontrib" > >> <myxyz:if ... > >> >> >> >> Costin >> >> Jose Alberto Fernandez wrote: >> > Hi guys, >> > >> > I was away on vacation so hasn't been around to make comments about the >> > entire discussion. I will try to sumarize here some comments that go >> > across several messages I have read today. >> > >> > The current <antlib> provides a way for the user of a particular antlib >> > to rename one or more elements that are in conflict with elements of >> > some other antlib it tries to use. As the renaming is local to the >> > project there is no problem; it is up to the user of the antlib to >> > decide what names to use to refer to the loaded things. For example I >> > may use the <foreach> class of antcontrib but for reasons of my project >> > being in need to also use a <foreach> defined by some other third party >> > which works diferently. So I could just load it and rename it lets say >> > to <forall> and use it in my project using that name. >> > It is up to me as the user of the antlib. >> > >> > From the discussion this last few days I like the idea from (I think) >> > Peter/Nicola of having short and long names where the long names are >> > form by adding a prefix defined not by the antlib writer, but by the >> > antlib user: >> > >> > <antlib location="antcontrib.jar" prefix="myxyz-" /> >> > >> > which would allowme to use either: >> > >> > <if/> or <myxyz-if> >> > >> > it is upto the user to decide what to use. Of course the same would be >> > for the tasks (i.e., <taskdef>) that allows loading individual tasks >> > into roles. The same rules of collisions and conflict resolution apply. >> > >> > The important point is for the user (which is the one who has to >> > deal with name clashes) to have control of the final naming scheme used >> > in his/her buildfile. And we are not impossing any wierd semantics or >> > making assumptions, if I decide to use the same prefix for two antlibs >> > it is up to me to make sure there are no conflicts. >> > >> >> -----Original Message----- >> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] >> >> Sent: 02 May 2003 14:35 >> >> To: [EMAIL PROTECTED] >> >> Subject: Re: Roles (was: antlib) >> >> >> >> >> >> On Wed, 30 Apr 2003, Jose Alberto Fernandez >> >> >> >> <[EMAIL PROTECTED]> wrote: >> >> > The problem you are overlooking is the case of <weblogic> element >> >> > in <ejbjar>, <jspc>, <serverdeploy>, etc. >> >> >> >> Maybe not really overlooking but understimating. >> >> >> >> The alternative would be to use <weblogicjspc> and <weblogicdeploy> >> >> for the different interfaces. If they come from different antlibs, we >> >> really should use XML namespaces to resolve this. >> >> >> >> But I now understand that having a table per interface may be >> >> convenient (though not strictly necessary). >> >> >> >> Stefan >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED]
