On Wednesday 14 May 2003 10:49, Jose Alberto Fernandez wrote:
> > From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> >
> > I am having a look at
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897
> >
> > 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/antcontrib.properties"
prefix="antcontrib."/>
<taskdef resource=".../antelope.properties" 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.properties"
uri="antlib:net/antcontrib"/>
<antcontrib:shellscript shell="bash"
xmlns:antcontrib="antlib:net/antcontrib">
echo Hello world
</antcontrib:shellscript>
</target>
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">
<antcontrib:if>
<available.../>
</...>
</..>
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.
Peter.
