Hi Marco, Adam, I appreciate your patience, in responding to someone who must come across quite poorly. It is pure frustration. And if I was not able to reign it in, in my email, I am sorry. Now, to the issue:
The question; "how do (I) get access to the classloader" is not a simple one. I am involved in the development of an application which; 1. loads its own .jar plugins 2. of which can have other dynamic .jar dependencies, specified in a XML descriptor resource file found in plugin .jar 1 it all gets a bit complicated, and so the classLoader resolution is similarly complicated. It iterates over the calling stack, and if it finds such a calling classes classloader where this classloader is a descendant of the current thread context ClassLoader, we use this. If not, we use the current-thread context-classloader itself i.e. final ClassLoader threadContextLoader = Thread.currentThread ().getContextClassLoader(); and in very rare problem conditions, the system class loader might be used. In otherwords, the classloader is chosen on the fly, programatically, depending on conditions. So, I debugged the junit test, as it run via ANT, and noticed that in that environment, it just uses the current-thread context classLoader. So, as a work-around, in order to get things working for gradle, i make sure it is possible just to use the current-thread context-classloader. Now those junit tests run in Gradle. However, I've got some re-coding to do before I can be confident of it working in all situations.... More motivation to write more junit tests I guess..... although, I would be then testing for error situations that only occur in gradle. I am definitely not a top java coder. But .... .geez.... regardless, classpath problems really stink. Kind Regards, Sean
