I did some investigation and I *think* I know whats going on with this
regression. If I'm right, the way it used to work is probably not
desireable anyway, so it would be good to discuss what to do about it...
What I think is going on:
GROOVY CLASSPATH INFERENCE
- The GroovyPlugin sets the classpath of the GroovyDoc task to the
compile classpath of the main sourceset
- The GroovyBasePlugin sets the groovyClasspath by using GroovyRuntime
to infer it from the (compile) classpath
- The inference mechanism looks for a groovy jar on the classpath
- If it finds groovy-all.jar it just uses that jar.
- If it finds a different groovy jar it creates a new configuration and
adds the jar as a dependency (I am not sure what this achieves over just
using the jar)
- It would make more sense to me if it added a 'tool' version of the jar
instead (in fact the comments say it *does* do this)
- This behaviour seems to have been changed by Adam in commit 818e0b9
- I suspect this commit introduced the regression
HOWEVER...
- The exception reported in the forums does not seem to occur when
executing the groovydoc tool itself, but when instantiating a gradle
BasicAntBuilder (in order to define and execute an ant groovydoc task)
- This is because BasicAntBuilder inherits from groovy.util.AntBuilder
- This is loaded by a classloader that by default has a classpath
containing classPathRegistry.getClassPath("GROOVY"), but this appears to be
replaced by AntGroovyDoc with the groovyClasspath from the GroovyDoc task
- This all leads me to suspect that this used to work (prior to Adam's
commit) by picking up groovy.util.AntBuilder from the users compile
configuration rather than from the gradle installation
- That doesn't seem desireable...
