Groovyc ignores includeAntRuntime when not forked.

I was wrong. Groovyc is not ignoring the includeAntRuntime property in non fork mode. This issue can be closed. Sorry.

I reopen the issue. I have observed the following behavior:

Ant Groovyc only takes includeAntRuntime=false into account if fork is set to true. Considering the fact, that the default for fork is false, this is a clear invitation to classloader hell. In particular, as Ant Javac considers includeAntRuntime=false in fork as well as non-fork mode and I guess this is what people would expect from groovyc as well. People using Groovy are also likely to use Groovyc via the AntBuilder from an application, which makes the issue even more critical, as the classpath then has usually more entries then just the ant libs.

The nested javac task of Groovyc takes includeAntRuntime into account. At least if I run my tests from compiled classes. If I run the script with the AntBuilder code via 'groovy bugtest.groovy' the includeAntRuntime has no effect on the nested javac task. For groovy-1.6-beta-1 I have observed, that the includeAntRuntime property can't be set any longer for the nested javac task.

What's really lacking here is a unit test or a self-contained example of how to trip it up so it can be created out of context of Gradle or GMaven or whatever else is tripping things up. I have a possible fix, but I am not sure if it would work and this would create a frustrating game of check-in ping-pong without some way to verify it myself.

Index: src/main/org/codehaus/groovy/ant/Groovyc.java
===================================================================
--- src/main/org/codehaus/groovy/ant/Groovyc.java	(revision 13862)
+++ src/main/org/codehaus/groovy/ant/Groovyc.java	Mon Nov 03 12:27:18 MST 2008
@@ -837,7 +837,9 @@
 
 
     protected GroovyClassLoader buildClassLoaderFor() {
-        ClassLoader parent = this.getClass().getClassLoader();
+        ClassLoader parent = getIncludeantruntime()
+            ? this.getClass().getClassLoader()
+            : new AntClassLoader(new GroovyClassLoader(null), getProject(), getClasspath());
         if (parent instanceof AntClassLoader) {
             AntClassLoader antLoader = (AntClassLoader) parent;
             String[] pathElm = antLoader.getClasspath().split(File.pathSeparator);

Patch is against 1.7-SNAPSHOT (svn head) could be tweaked to go against 1.6 branch and (with a bit mroe tweaking) 1.5.

Thanks for looking into this. I will try to attach a test case tomorrow or the day after.

Hans, any luck getting time to look at this proposed fix?

My apologies for having forgotten about the test case. Here it is now. The zip contains a project. The project has a src dir with one groovy class. This class has a reference to a class from commons-math. The testscript uses the groovyc ant task, to compile the source class. No classpath elements have been assigned to the groovyc task.

If you execute the test script with groovy testscript.groovy, the compile fails, as it should be. There is no commons-math in the classpath.

If you execute the test script with groovy -cp lib/commons-math-1.1.jar testscript.groovy, the compile succeeds. This should not be the case, as we have set includeAntRuntime to false. If the isolation were working, you would need to assign the groovy and commons-math jar to the groovyc classpath to have a successful compile.

I had no time yet to give the above patch a try by myself.

I have applied a modified version of Danno's suggested patch. It seems to work for me for the test cases I have devised. It would be great if someone else can try this out (grab trunk or a CI server output artifact).