Jose Alberto, I have the following problems with your proposal:
1. It assumes that jars used by Ant should be placed into sub-directories of the Ant install directory. I know Ant is the centre of the Universe but I don't think we should be encouraging everything to end up in there. I know this happens today with the lib directory. I'm not happy about that but I think this proposal will just magnify the problem. 2. It ties the operation of a build file to the configuration of the user's Ant subdirectories. If the link is implicit, it will not be obvious. This could be become a maintenance nightmare. Consider this scenario User: I downloaded your build file and it didn't work Build Writer: Oh, you need to set up your directory structure this way (...) User: OK I did that and it broke half my other build files. They game me a different setup. If the link is explicit it will be worse. User: The Tomcat build uses classlaoder "A" for foo.jar but Xerces uses "A" for jaxp.jar. If I put JAXP in "A" it breaks Tomcat build. What shold I do? BuildWriter: Ahhh ... 3. The proposal isn't hierarchical. If b1.jar depends on a1.jar (since it uses a type defined in a1.jar, for example) it must live in the same directory. If b2.jar also depends on a1.jar but is incompatible with b1, you have a problem. For example, we have problems today where some tasks conflict with Ant'2 JAXP classes. 4. Adding classes to a classloader after it is running may be dangerous if these classes have already been loaded by a child classloader. > -----Original Message----- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 20 February 2002 1:01 PM > To: Ant Project List > Subject: Dealing with ClassLoaders > > > Hi, > > 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. > > In the <antlib> proposal I am trying a different approach. Still > certain things, like core, will go in > the CLASSPATH, to obtain backward compatibility. Additional > Classloaders will not be defined > by the jar files being added but by name. Every time a library is > loaded, one specifies (implicitly or > explicitly) the ClassLoader to use for loading its content. > > In other words instead of creating more and more classloaders, > one just add more and more > classes to an (maybe) existent classloader. By being able to > identify which one we one to use > we can accpomplish selective segregation of the classes when > there are dependency clashes. > > The third aspect, which I am considering right now, is to have > three predetermine locations for > libraries: > > 1) $ANT_HOME/lib: this jars are added in the JVM's classpath. > > 2) $ANT_HOME/autolib/* : Any jars in subdirectories will be > loaded at start-up on ClassLoaders > identified by the name of the subdirectory. > > $ANT_HOME/autolib/A/{a1.jar, a2.jar} : > a1.jar and a2.jar will use ClassLoader "A". > > $ANT_HOME/autolib/B/{b1.jar, b2.jar} : > b1.jar and b2.jar will use ClassLoader "B". > > this will allow related libraries to se the same classloader and > eliminate many of the current issues. > > 3) $ANT_HOME/antlib: this is the location for libraries to be > loaded on demand by using <antlib library='x.jar'> > and one can specify which classloader to use. > > To me this mechanism is much more simple to administrate, since > in general people can first try loading > everything in the default Classloader, and in case of a conflict > they just need to change where they want > to see what. > > Comments, thoughts, > > Jose Alberto > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
