ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: antlib / proposal of Peter Reilly
Date Wed, 14 May 2003 12:18:41 GMT
On Wednesday 14 May 2003 10:49, Jose Alberto Fernandez wrote:
> > From: Antoine Levy-Lambert []
> >
> > I am having a look at
> >
> >
> > This proposal seems to address most of the points discussed
> > in this mailing list concerning the antlib thread of discussion.
> >
> > I was thinking maybe we do not need to look further and we
> > could commit this contribution ?
> >
> >
> > I would be glad to hear your comments concerning :
> > 1) the functionality provided by the contribution
> > 2) the implementation
> Well I have not given the fight on the need for roles and separate
> symbol-tables for different Types. 

Roles/separate symbol-tables could be dealt with later.

>I would like for someone to explain
> how <ejbjar>, <jspc>, <serverdeploy> can have vendor dependent
> <weblogic>, <jboss>, etc. within this model.
> > I am quoting Peter Reilly here :
> >
> > This patch adds 4 new features (the code is interrelated,
> > but may be split).
> >   * adapter attribute added to typedef
> >   * add(Type) method added to introspection rules
> >   * typedef can read an xml defintion file
> >   * namespace support for xml defintions (antlib:)
> > So one can do
> > <project xmlns:acme="org.acme.anttasks">
> >    <acme:hello>
> >       <path path="build.xml"/>
> >    </acme:hello>
> > </project>
> > where the class path contains the org/acme/anttasks/antlib.xml
> > and the antlib.xml file contains:
> > <antlib>
> >    <typedef name="hello" classname="org.acme.anttasks.Hello"/>
> > </antlib>
> As I have mentioned before, I have problems with this. It means that
> users are forced to use name spaces even if there are no collisions
> on the names of the components in the antlib, just because there is no
> way to find the antlib.xml otherwise.
> I do not see an <antlib> task specified in the project, does that
> means that I need to put all the jars in the classpath of ANT?
> I hope that is not a requirement. I think users need to be
> able to specify the classpath they want to use for their
> libraries just like they do for <taskdef>.

My description was not very detailed.

I have extended "typedef"/"taskdef" to process an xml definition file (an
antlib xml file) in the same way as properties are dealt with
at the moment.

for example:

<typedef resource="org/acme/mydefinitions.xml" classpath="classes"/>

to allow loading of tasks/types from different 3rd party with some tasks
haveing the same name, I have added a "prefix" attribute.

<taskdef resource="net/sf/antcontrib/"
<taskdef resource=".../" prefix="antelope"/>

To use XML name space, I have placed in code to deal the ns uri starting
with "antlib:". This can be used with the "uri" attribute to typedef.

  <target name="antc">
    <taskdef resource="net/sf/antcontrib/"
    <antcontrib:shellscript shell="bash" 
         echo Hello world

To be a little bit more userfriendly, (and to support the notation
discussed in the e-mail discussion) the code treats the
ns uri antlib:<package> as follows:
when it is first encountered the code converted the '.' to
'/' and adds /antlib.xml. The code when checks if the resource
of that name is present and if so loads it up.

This logic is partially implemented by the "antlib" attribute to typedef.
  <typedef antlib="antlib:net.sf.antcontrib"  classpath="classes"/>

this will check if the resource net/sf/antcontrib/antlib.xml exists
and if so it loads the definitions into the antlib:net.sf.antcontrib ns uri.

If net/sf/antcontrib/antlib.xml is in the class path, (for example
in a jar in ${ant.home}/lib or placed in the class path by
<classloader/>), one can specify the ns at the <project/> element

<project xmlns:antcontrib="antlib:net.sf.antcontrib">

I realise that the "prefix", "uri" and "antlib" attributes may not
get acceptance, so in the html page of "typedef", I have labeled them
as "Experimental".

> > ToDo: add in support for ant-type polymorphism and
> > addConfigured(Type).
> >       also more error checking and unit tests.
> ant-type polymorphism is not a priority for me, but
> addConfigured support is. Given the fact that the
> objects being passed are opaque for all purposes of
> the parent element, it makes little sense to pass an
> uninitialized object to the parent (which is what add(Type) does)
> instead of passing an initialized object (what addConfigured(Type)
> should do).

I do not agree that it does not make sense to pass the
uninitialized object. Normally one saves the object in a container
in the add method, and uses the (now configured) object in the
#execute() method of a task.

However, I have updated my code to implement "addConfigured(Type)" as
well as add(Type) and will update the patch later.


View raw message