ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: antlib and classloaders
Date Fri, 02 Apr 2004 13:50:26 GMT
> From: Peter Reilly [mailto:peter.reilly@corvil.com] 
> 
> 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: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message