--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Thu, 21 Feb 2002, <[EMAIL PROTECTED]> wrote: > > On 21 Feb 2002, Stefan Bodewig wrote: > > >> >> What do people think of breaking optional.jar > into several > >> >> pieces cut along the dependencies, > optional-junit.jar, > >> >> optional-trax.jar and so on. > > > > +1, great idea. > > > > What I don't like is the fact that we load > optional.jar and what's > > inside in the 'parent' class loader. > > This is what I've called "the problem that cannot be > fixed in a > backwards compatible way" - I'd be happy if you > could prove me wrong. >
If we keep all those classes in one big lump there is little chance of keeping backward compatibility. Now, once you chop it in pieces new posibilities araise. This and the addition of an autoload mechanism on separate loaders, can help solve the problem. After all if in a particular project people are using a task that requires certain classes living in the CLASSPATH you can always put them back in there and nothing is lost. > The main classloader problem of Ant 1.x is, that > there is far too much > stuff on the system classloader IMHO, but I'm really > afraid that there > are lots of people who rely on Ant having its own > classes just there. > > > I liked very much the idea of using named loaders, > and a model > > similar with what tomcat is using ( either > version, but 3.3 in > > particular :-). > > Your description sounds a lot like Conor's of > Mutant's class loader > hierarchy (see proposal/mutant/docs/desc.html) and > Myrmidon does > something similar IIRC. So you we all basically > agree that having a > class loader hierarchy like that is the way we > should go - > unfortunately this is not backwards compatible for > the things that > have been shipping with Ant before. > For what I remembered of his description of classloader hierarchy, I think it is too limiting. If libA needs things from libB, his approach will declare that "libA extends libB" which is fine unless libA also needs things from libC. Now you cannot do it because we have single inheritance (i.e., a classloader onl has one parent classloader). This is why I use named loaders. Each name loader defines a group of libraries(jars) that need to work together. if libA requires libB and libC you just put all of them on the same loader, 'loaderABC'. I use parent classloaders to solve a different problem that we have, and which I think it is a BUG not a feature: we do not unload the classloaders once we live the subproject that created them. What antlib does is that the named loaders hierarchy reflect the hierarchy of subprojects. So if subproject X adds a libD to 'loaderABC' what you get is a new classloader whose parent is 'loaderABC' from the parent project and which contains libD. When you get out of X you release its instance of 'loaderABC' but still have its parent instance. It is simple, and covers more. This is exactly what the Class-Path manifest entry tries to acheive but without hardcoding in the libraries the names of other libraries. The thing that puts everything together and gives the backward compatibility, is the autoload feature into named classloaders. That will give users the impression that all tasks are there where they need to be. And after all if for some reason you really need to have one of them in the CLASSPATH, you can always do that by moving it to ant/lib. > If we start shipping new tasks in extension > libraries that get loaded > from named class loaders, that is fine, but for the > things that used > to be on the system classloader, we must still > ensure they stay there. > Well, we now tell people to take them out of there so things will work, so I think the autoloading is a much better solution. As for the core tasks, those should stay in ant/lib since after all they are core. Jose Alberto __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
