ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: antlib / proposal of Peter Reilly
Date Wed, 14 May 2003 09:49:43 GMT
> 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. 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>.

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

Jose Alberto

View raw message