Thanks for the detailed reply. I will reply in-line. However, I think that I did not make my main point clear in my original e-mail. So I will detail it first.
Currently 3rd party add-ons to ant are done using <typedef/> and/or <taskdef/>. These can either define the tasks or types in-line or by using property files ( as a file or a resource). Using property files is nice but with new attributes to typedef (adaptor for example) it would be better to use an xml file/resource. 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 ;-)). On Wednesday 07 May 2003 15:56, Costin Manolache wrote: > 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 ). 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. > > 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" > > > - 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. > > 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 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> > 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. :-) > > 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 ). I mean that one does not need to use jars for this. The class path is sufficient. > > ( 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 ! I have work in progress code for this :-). > > > 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. > > 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 ? 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.... Peter
