ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: How to provide reusable ClassPaths in ANT
Date Tue, 17 Dec 2002 15:48:31 GMT
Jose Alberto Fernandez wrote:

> Definer only addresses a segment of the problem (a very worthy segment I
> admit) but there are still many tasks that use a <classpath> not to load
> themselves but to load other classes. All the EJB stuff is like that.
> Compilers, etc.
> 
> So there is still a need for some general facility.

I agree. Would it be possible to use the same mechanism as definer ? 

If not, it would be nice if definer would be also modified to support
the new mechanism.

Some time ago I made a proposal similar with yours ( associate
all <paths> with a classloader ). I think an explicit <classloader>
task would be much better. 

Something like:
  <classloader id="myLoader" >
    <path refid="..."/>
  </classloader>

And 
  <classloader id="ant.loader">...</>
This form would set ( modify?) the main loader. Very usefull for 
junit and similar optional tasks ( if you don't include everything
in ant/lib ). 

BTW, JMX has an interesting model with a loader repository where all
class loaders are registered, and it'll look into all loaders in a 
repository when trying to create an mbean. ( you can also request an 
explicit loader).


Costin 

> 
> Jose Alberto
> 
>> -----Original Message-----
>> From: Costin Manolache [mailto:cmanolache@yahoo.com]
>> Sent: 17 December 2002 05:20
>> To: ant-dev@jakarta.apache.org
>> Subject: Re: How to provide reusable ClassPaths in ANT
>> 
>> 
>> If you check Definer.java, there is already a way to reuse a
>> classloader.
>> 
>> 
>> Costin
>> 
>> 
>> Jose Alberto Fernandez wrote:
>> 
>> > One of the things that most anoyed me of the current
>> architecture of ANT
>> > if the way ClassPaths are managed during the build. Almost
>> every task
>> > that can be passed a <path> for finding classes, creates its own
>> > AntClassLoader. As a consecuence ref-ids become
>> incompatible very easily
>> > unless the classes are all on the system classpath.
>> > 
>> > By creating AntClassLoaders on those indifvidual tasks we
>> are forcing ANT
>> > to reload class definitions a lot, which has to slow things
>> down, IMHO.
>> > 
>> > I do not have a full solution (backward compatible and
>> all), but would
>> > like to propose doing some brainstorming to find a better
>> way to do this
>> > (at least on most cases).
>> > 
>> > Here are some ideas I have been thinking about, for you
>> guys to shread to
>> > pieces:
>> > 
>> > We continue declaring <path>s the way we do, but allow to
>> specify caching
>> > of classloaders:
>> > 
>> > <path cacheclasses=true>
>> > ...
>> > </path>
>> > 
>> > The Path class will have a new methods:
>> > 
>> > ClassLoader getCachedLoader();
>> > void setCachedLoader(ClassLoader cl);
>> > 
>> > these methods would be used by AntClassLoader to decide whether to
>> > actually create a new ClassLoader of simply delegate to the
>> cached one. So
>> > users will continue to use things as they do today, and
>> just the internals
>> > of this implementations will know about this things.
>> > 
>> > Of course, we still need some rules to decide when it is
>> safe to use the
>> > same classloader and when not. Given the configuration of
>> the Path object.
>> > 
>> > Any comments, ideas, do you guys thing there is any hope on
>> something like
>> > this to work?
>> > 
>> > Jose Alberto
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:
> <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>




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


Mime
View raw message