From: "Stefan Bodewig" <[EMAIL PROTECTED]> > On Fri, 22 Feb 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > 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). > > That's not my understanding. libB would cause libA and libC to loaded > a second time, this time in a class loader accessible by libB. > > > 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. > > So we'd tell people "if you encounter class loader problems in Ant > 1.4.1, you most likely have to move some jar out of ANT_HOME/lib and > if your encounter them in Ant 1.5 you have to move some jar into > ANT_HOME/lib"? >
Yes, that should not be necessary for tasks shipped from jakarta-ant. It is just if people have their own tasks that make bad assumptions about things in CLASSPATH. In 1.4.1 we are telling people that to be able to use our own jakarta-ant tasks thay need not only to change the content of ANT_HOME/lib but to actually much with the content of the jars we ship. Now if that is not extremely bizzar(sp?) I am waiting for someone to explain me the logic of that. > > As for the core tasks, those should stay in ant/lib since after all > > they are core. > > <style> is a core, as is <mapper> and both frequently cause the known > problems. Are we using the TreadContextClassLoader properly on those tasks? This should not be hapenning if we where doing things correctly. Yes, maybe in a JVM1.1 you may need to put more things in the CLASSPATH but hey, you have to give people some reason to update ;-) Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
