ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Roles (was: antlib)
Date Fri, 09 May 2003 03:08:23 GMT
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
> allows one to do somthing like this:
> <project  xmlns:html=''>
>    <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

>> 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=''>
>    <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.


>> > 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.


>> > 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:// :-)


View raw message