> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > Mariano's original question was why > was classpath ignored in an antlib definition. > > <antlib> > <typedef name="task" classname="org.mytasks.Task" > loaderref="mytasks.ref"> > <classpath> > <fileset dir="${env.MY_TASKS_HOME}/lib" includes="**/*.jar"/> > </classpath> > <typedef name="task2" classname="org.mytasks.Task2" > loaderref="mytasks.ref"/> </antlib> > > > This could be supported easily in the current code base. > -i.e. if an typedef/taskdef in an antlib sets the classpath, > this classpath will be used instead of the antlibdefinition classpath. >
Maybe the parent classloader should be that the antlibdefinition classpath. But yes I agree with you. > The only problem with this is that the user build script > needs to set the correct property before the antlib is activated. > Which I think it is not much to ask. I have a conceptual problem of usability on an antlib written like this, remember, in the broader sense, the antlib is written by a third party for the usage of unrelated users in unrelated projects. Having a classpath in there, constricts the user of the library to follow whichever layout criteria the third-party decides. Which does not seem to be right. Now, that does not mean that I am against such capability, to use in very closely controlled projects. Jose Alberto > Peter > > > Mariano Benitez wrote: > > > I have this issue in mind: > > > > Since I need to provide antlibs to my customers, I would > like them to > > have to manually configure as less as possible, that means that the > > previous way of saying -b <myapp>/antlib was quite cool. > > > > The problem is that I do need to control the classloader where the > > tasks are loaded, because I cannot copy the whole list of > jars in my > > app to the antlib classpath. Maybe by just copying ONE jar > to antlib > > is just fine, and inside the antlib.xml control the classloading. > > Maybe only making the antlib.xml file available in the ant base > > classpath would be another way. > > > > Following your proposal, inside my antlib.xml I would define the > > classpath for the antlib itself, leaving all configuration inside > > there, and not having to manually define a classpath outside the > > antlib. I know this can be achieved by using an <import> > task, that is > > the solution I will implement in 1.6.1, but having all the > > classloading issues inside the antlib file itself is more > simple for > > the user of the antlib. Also reduces the main ant classpath. > > > > Well, those are my 2 cents, hope is clear, antlibs are great and I > > would like them to keep evolving and making it better. > > > > MAriano > > > > Jose Alberto Fernandez wrote: > > > >> Hi, I have been giving some thought on ways to solve this nagging > >> issue of needing to put antlib jars on the lib directory. > >> > >> We hear over and over people wanting to keep their third party > >> libraries out of -lib because they are only for an > specific project. > >> > >> As I see it, our road block has been how to tell in > succinct way in > >> the buildfile that when loading the namespace "antlib:foo.bar" you > >> should use this or that classpath or classloader. A simple > solution > >> could be to achieve this by name association: > >> > >> - When ANT tries to find and load the resource for > "antlib:foo.bar" > >> it will first look for a reference named "foo.bar" representing a > >> classloader (or classpath?). If an object of the correct type is > >> found, then this classloader will be user for resolving > and loadding > >> the antlib, otherwise the default classloader will be use, > as it is > >> today. > >> > >> So with this in place, one could write things like: > >> > >> <project name="x" xmlns:lib="antlib:foo.bar"> > >> > >> <classpath id="foo.bar">.....</classpath> > >> > >> <lib:mytask ..../> <!-- The antlib loaded using the > classloader for > >> "foo.bar" --> > >> > >> </project> > >> > >> Before jumping on a code proposal, does this sound a the right or > >> good solution? Does this cover enough of the use cases? > >> > >> Let me know what you people think. > >> > >> Jose Aberto > >> > >> > >> > >> > >> > >> > >> > --------------------------------------------------------------------- > >> --- > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
