From: "Stefan Bodewig" <[EMAIL PROTECTED]> > On Wed, 20 Feb 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > One of the things I think is broken in ANT1 is the way we deal with > > ClassLoaders. Our current approach of having some of the code in the > > CLASSPATH and any other code being loaded on independent > > ClassLoaders just causes all kinds of problems that only can be > > solved by putting everything in the CLASSPATH of the JVM. > > Not true, it can also by solved by removing stuff from the CLASSPATH - > i.e. splitting optional.jar into several pieces and remove the ones > you don't want to have in CLASSPATH from ANT_HOME/lib. >
You mean I have to reconfigure my installation of ANT everytime I decide to use a new task in my project? That is no solution in my book. > This is not taking away anything from the fact that the current > situation is broken. > > > In the <antlib> proposal I am trying a different approach. > > Don't try to do too many things in that proposal at once ;-) > What can I say, I like holistic solutions :-) > Both Mutant and Myrmidon have very similar ideas on using > classloaders, and their ideas solve most of the problems we currently > have. Almost nothing is on the system classloader. > Those types of solutions, which I proposed in the original <antlib> maybe 6 months ago, are not compatible with ANT1.x as Peter was very keen in pointing out. > I'm not sure that we really want to solve the classloader problems in > Ant 1 - and if we really can without breaking backwards compatibility. > Well I want to use <ejbjar> without needing to put weblogic inside ANT, and I want to use saxon for certian transformations eventhough the optional.jar contains other stuff. And I reall do not want to have to maintain my own packaging ot the ANT tasks. What I am proposing does not break backward compatibility. And I think they give much greater control on which classes need to be provided by which classloader. Segregation and inheritance of classloaders in not enough (and that is my understanding of what those proposals offer). > In the context of the <antlib> or <import>, we may be able to define > new rules that are roughly forwards compatible, but I don't think we > can change things for tasks that are not explicitly part of an > imported library. I guess you are assuming myrmidom and mutant rules are there to stay, I would like to live that door open. ;-) Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
