peter reilly wrote: > Using property files is nice but with new attributes > to typedef (adaptor for example) it would be better to > use an xml file/resource.
I think we already agreed on XML - there is no reason to continue adding arguments. > This should be independent of using antlibs/jars or XML ns. > Hence I think that the root element name should not be > "antlib" as this implies more baggage. > (Also my work in progress implementation uses an ant task > for the xml parsing and the root element name is the task > name ;-)). That's what I would do too ( and why I suggested using ant xml processing for the antlib descriptor ) :-) What "baggage" are you talking about ? Antlib is what we are trying to do, it would be confusing to use another name for the root element. >> > 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 ). > > The NS standard http://www.w3.org/TR/REC-xml-names/ > allows one to do somthing like this: > > <project xmlns:html='http://www.w3.org/TR/REC-html40'> > <target name="t"> > <echo html:class="reallyimportant">message</echo> > </target> > </project> > > of course it is up to the ant software to understand the xml file, > but "unsupported attribute 'class'" is not a usefull error message > in this case. Yes - but let's first implement namespaces on the elements. We can add code to ignore ( for now ) attributes that are in a different namespace than the element - that would allow various annotations or 3rd party tools. After we see how people use namespaces - we can add more features for the attributes. >> 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. > > This is true, but using namespaces one could do: > <project xmlns:html='http://www.w3.org/TR/REC-html40'> > <html:target name="t"> > <echo>hello world</echo> > </html:target> > </project> > > which is clearly wrong - but with the current code gives the > misleading error: > "Could not create task or type of type: target" There are plenty of wrong things one can do :-) We can fix the message to say "html:target" or use the URI, it's not a show stopper. >> > - 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. > The idea is to allow a xml ns to be used for purposes other that defining > Unknown Elements. My example was an antdoc xml ns. Still don't get it. PH2 creates an object tree - and various element in the tree can access the tree and do whatever they want. PH2 itself shouldn't be involved in this. >> > 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 > It does matter from a build script point of view. > > <addon:copypath> > <path refid="x"/> > <remoteurl url="http://"; retry="no"/> > </addon:copypath> > > is different from: > > <addon:copypath> > <addon:path refid="x"/> > <addon:remoteurl url="http://"; retry="no"/> > </addon:copypath> The first case is simple - the current rules cover it. For the second - I don't know how could we handle it with the simple patterns ( createPath / addPath ). What's your proposal ? To apply the simple patterns to the local name ? >> 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. > Actually I think change is easy enough. :-) Sorry, I don't understand exactly what behavior you want. >> > 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 ). > > I mean that one does not need to use jars for this. The class path is > sufficient. +1 >> > 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 ? > > As I said above my implemation uses an ant task for this, using the same > name for the root element of the descriptor and for a different task would > cause interesting problems for the implementation. Ok. >> > 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 ? > > I mean that I am making no assumtions on the location of the > definition file, in the class path, or in the jar or in the meta-data > part of the jar or meta inf attribute pointing to the xml file or having > two xml files one pointing to the other.... Ok. Well - even if the NS is not used to load the descriptor, I still think it would be good to at least recommend the package to be used as ns. ( and certainly not http:// or file:// :-) Costin
