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