Hi. I’ve just created a problem topic about jettyRun and the classpath. I also had similar problems with the tomcat-gradle-plugin, and there the author seems to be starting his own classloader to explicitly filter out Gradle’s jars. Yet somewhere else I read some words from the Kotlin plugin’s author that he has similar problems. I will be giving a presentation on Gradle at my company next week, and we will see if we can start using it (we are now maven 3 and more and more people notice its problems - yes, we are slow). However, we mainly write webapps, and we like to start some containers for our testing during the build. We have had enough classloading issues with groovy, asm, cglib, hibernate, spring, slf4j, logback and so on, so that the last thing we need is hunting ghosts while running tests within Jetty / Tomcat embedded in the build process. I will definitely have to mention that the classpath is somehow wrong.
So, I would like you to answer me a few questions about the classpath, or maybe point me to some documentation so that I can read it myself: 1. There is no possibility to have separate classpaths for plugins / tasks, I can only define script-global classpath libs, correct? Or are these libs build-global, i.e. libraries introduced in the parent module will also be available in the child modules? 2. Do plugin developers (we will have custom plugins) wanting to manage the classpath have to come up with their own ways of forcing loading only the things they need? Just as the tomcat-gradle-plugin author does? 3. Do all plugins have always access to the same global classpath? (This is actually a rewording of the previous two.) Like, the compileJava task having gradle jars on the classpath? Seems not to be the case - why does then the Jetty plugin have the jars in runtime? Why is it different from the Compilation tasks? 4. Is there a standard way plugin authors can add custom classpaths? I am aware that I can add a new configuration, but how difficult is it to fetch its classpath when the task is about to be executed? I guess I have access to Project and can look it up and iterate over the jars, is this correct? Does Gradle download jars from such custom configurations or do plugin developers have to explicitly trigger it? 5. Is this by design that, apparently, the classpath is per-script and tasks see it as well? Are there plans to change it? I think this is one area where maven is much better - I have classpath per goal. For example, why would the jetty plugin or whatever know about some ssh jars that are in the build classpath only because I deploy via ssh?