ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: How to provide reusable ClassPaths in ANT
Date Tue, 17 Dec 2002 19:50:14 GMT
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. 

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

> 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 :-)

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

<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 :-)


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

View raw message