One thing I get really nervous about is always having a junit.jar in ant/lib and then one in the project itself so the project compiles. I know, I know, classloader stuff. But I had a suggestion around some of that, and I think I have seen similar comments.
I only suggest this as I wrote an xml scripting framework that is more dynamic than ant(I didn't have the backwards compatibility baggage making my job much easier). Trying to open source this through my company, but that is another story. Here is how my dream ant would work 1. junit would have an ant task and have some standard file ant/resource.xml and other jars could have the same file 2. junit is dropped into ant/lib or put in ant's classpath, or via a taskdef loaded in. 3. ant seeing this jar with a resource.xml automatically loads it in a different classloader(it has to actually otherwise it may get the resource.xml from a different jar on accident). It then configures itself and works. 4. The other option is someone does a taskdef with an attribute of jar="junit.jar" They don't need to even know the classnames of the tasks in the jar. That is all defined in the resource.xml. I have done this on a very similar scripting xml framework(I looked into jelly, but jelly didn't offer asynchronous tasks). This seems to work fine and would seem to solve your problems with the worry about users having a hard time. It would be quite simple. Drop your junit.jar into ant/lib, or in the classpath, or define <taskdef jar="junit.jar"/> in the build file. Either way, junit.jar would be loaded in a separate classloader. You may be wondering, but wait a second, you put the junit.jar on the classpath. That means it is now already loaded in the parent loader. Well yes, BUT what my framework does to get around that is reload the same framework in another classloader that doesn't have a parent. Then I take each and every jar off the classpath and load each in it's own classloader getting a reference to it's resource.xml file. Basically, no matter which of the three mechanisms are used 1. junit.jar w/ant task inside it on classpath 2. junit.jar w/ant task inside it in ant/lib 3. junit.jar w/ant task insitde it defined in <taskdef jar="junit.jar"/> It is loaded in a separate classloader and the task and junit library are together. Hopefully, I can drive the open source of this scripting framework through, and some could take a peak if they were curious. Thanks, dean
