On 2002.12.17 10:48:31 -0500 Costin Manolache wrote: > 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). >
Indeed, this is one of the more blatant advantages to rewriting ant to be a set of mbeans running in an mbean server. david jencks > > 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]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
