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 Wed, 07 May 2003 14:56:04 GMT
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.


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 ?


> 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 []
>> >> Sent: 02 May 2003 14:35
>> >> To:
>> >> Subject: Re: Roles (was: antlib)
>> >>
>> >>
>> >> On Wed, 30 Apr 2003, Jose Alberto Fernandez
>> >>
>> >> <> 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:
>> >> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

View raw message