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:[EMAIL PROTECTED]
>> Sent: 17 December 2002 05:20
>> To: [EMAIL PROTECTED]
>> 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:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
