This one was not only proposed before, but the code was provided for the fix. And Peter, veto it (if I remember correctly). The reason was the same as now, "I have task that assume everything is in the CLASSPATH and is you do this they will stop working".
I still think we should do this and have some option for putting things in the CLASSPATH for those that use misbehaved tasks. It would solve so many problems. Jose Alberto From: <[EMAIL PROTECTED]> > On Sat, 13 Jul 2002, Peter Donald wrote: > > > >2. Classloader improvements. I would like to use a different > > >startup procedure, and allow the use of a class loader hierarchy > > >similar with what tomcat is using. In particular, the startup > > > > This will break almost all the custom tasks I have written and probably > > alot of other peoples tasks if they create their own classloaders. > > Not sure I understand what will brake. I'm not talking about putting > ant implementation in a separate loader, like tomcat does - just > have a small Bootstrap that creates an AntClassLoader and puts > everything in lib/ in it ( like the shell is doing ). > > It is possible to put some jars in CLASSPATH ( like they were before ) > if needed. > > The only difference is that by using AntClassLoader to load ant.jar > and optional.jar it is possible to add more .jars at runtime - like > junit.jar - to the same loader. > > Obviously if Gump brakes - I'll try to find another solution, but > Class.forName and creating a class loader using the current loader as > parent will continue to work. > > Do you have any example ? > > Costin > > > -- > 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]>
