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 Wed, 18 Dec 2002 20:04:22 GMT
Jose Alberto Fernandez wrote:

> Costin, I think we agree more than you think,
> so I will try to explain myself a little more:

I think we are just discussing alternatives and use 
cases- and the good/bad for each one. After we know all options
we can agree ( or disagree ) on one :-)

We seem to agree that we need to solve this problem.

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

The problem I have - a Path shouldn't have to know about class loaders
or have class loader specific code.
IMO a ClassPath shouldn't know about class loaders either - you can
have the same path used by multiple loaders, and the concepts are different.

We need a ClassLoader task - and mechanisms to fine tune the loader
options ( delegation, parent, etc ) and a mechanism to have one or
several ClassLoaders used by tasks that need it.

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

Why do you preffer the latter ? I'm curious, in my mind a classpath (or 
path) is a different concept from a class loader. 
One is a collection of paths ( dirs, files, etc ), the other is 
one object that creates Classes. 

> 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 the cost is mixing the path and loader concepts - I think we'll
disagree on something :-)

Tasks that use Paths could just construct a classloader and
associate it with the path ( that should be few lines of code ).
If you need to load classes in a task - you need to create 
a classloader anyway, and the behavior would be the same
if you do Path.createLoader() or ClassLoader.createLoader(Path).

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

And you'll need another parameter to specify if you really want
to use the cached loader or not. 

Having a path associated with multiple loaders is very common
( reloading is all about that - you create another loader from
the same path and drop references to the old one ).

My primary issue is the separation of the concepts. A loader
is not a path, and a path is not a loader. A ClassLoader task
may use several path parameters, and may use AntClassLoader as
an implementation. 

> What I am envisioning now is something like:
> <classpath id="compiled-classes">
> <pathelement .../>
> <path .../>
> </classpath>
> <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"/>
> ...
> </ejbjar>
> 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.

There are some cases where both a path or a loader could be used. That
doesn't make them the same thing.

For compilation - you need to use a path. For loading classes - you need
a loader. For available - you can use either.
I don't see a need to have a distinction between path and classpath,
but I think it is very important to have loader and (class)path separate

BTW, it is also possible to have a loader that doesn't have any associated
path, or has a path that may change during execution ( for example 
when you load a file from a jar, it may process the manifest and use
additiona ClassPath elements ).  


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

View raw message