ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: How to provide reusable ClassPaths in ANT
Date Wed, 18 Dec 2002 17:28:48 GMT
Costin, I think we agree more than you think,
so I will try to explain myself a little more:

> From: Costin Manolache []
> Jose Alberto Fernandez wrote:
> > The only issue here is how to retrofit all the tasks to be 
> able to use the
> > new feature, that is quite a big job, I think.
> Using the Path.getCachedClassLoader() is almost the same thing with
> using Project.getReference(..) or a new API.
> I don't think all tasks will need to be modified - only few of
> them. I already made a change in Project to create the task instance
> just before use - and to use the 'core' loader. 
> I think that would take care of a lot of use cases. 

The usage of the core loader is fine. Also notice that the additional methods
I suggested for Path (which should be really part of this new 
ClassPath or ClassLoader task), are not to be called by the calling tasks
but by deeper infrastructure. So there is no changes to the tasks code.

> > This is why I proposed modifying <path> or maybe making 
> <classloader>
> > extend <path>, that way we would hardly need to do any 
> changes to the
> > using tasks and could embed all the glue necessary on 
> > itself.
> <classloader> should extend <path>, I agree. But I think it would be
> cleaner to keep them separated ( as syntax ). 

I have no problem with that, I agree with you.
So we will have: <path> and we will have <classloader> or <classpath>
(I kind of prefer the latter) which should be used for things that
want a path to load classes.

> I don't understand very well what you need ( use case ), most of my 
> use cases are covered by the existing code. Tasks that use a separate
> loader should include the reference to the class loader they want
> or use the core loader. The code change is very small, and 
> AntClassLoader
> already have the ability to change its path at runtime ( i.e. 
> add more 
> locations ).

This would mean that every <task> that accepts a Path element
today for classes would have to accept something else if they want to use
a predefined classloader. I would like to avoid that.

> > If you pass to the constructor a <classloader> as the Path 
> instance, it
> > will just delegate all calls to that ClassLoader and 
> efectively implemet
> > sharing eventhough the code still thinks it is creating separate
> > ClassLoaders all over the place.
> Passing something to a constructor is certainly not a good idea :-)
> I think using a ref is the cleanest solution. 
> BTW, don't forget the thread class loader :-)

I am talking about the constructor for AntClassLoader which already
has a Path parameter. The point is that if the Path parameter
happens to be a ClassPath (or ClassLoader) instance then it should
try to use its cached java ClassLoader, if possible.

> > Maybe there is a better way, some of the tasks do really 
> strange things
> > with their Path instances. But hey lets keep on talking.
> > :-)
> It would help if you send some specific use cases ( that are not 
> covered by existing code and would need changes in AntClassLoader ).
> I'm not sure what limitations you see in using a classloader ref.

Look at all the ejb related tasks, they do not use the ClassLoader to load
themselves they use it to find the code to process.

> <taskdef> creates the loader implicitely, but you can easily
> add a <classloader> task to create explicitely whatever loader you
> want and use whatever id ( you can also specify a parent id, 
> delegation,
> etc ).
> My biggest concern is to keep the syntax intuitive and simple - so
> I can replicate the same syntax in tomcat config file :-)

That would be very nice.

What I am envisioning now is something like:

	<classpath id="compiled-classes">
		<pathelement .../>
		<path .../>

	<available classname="my.code" classpathref="compiled-classes" .../>
	<available classname="your.code" classpathref="compiled-classes" .../>

	<ejbjar ...>
		<!-- this element expects a Path object -->
		<classpath refid="compiled-classes"/>

All this things will be using the same ClassLoader cached in <classpath>
but there will be no need for changes in the code of this tasks,
well in most cases.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message