GRADLE-3220: Fixing the Groovy annotation processor classpath isolation problem

[Will Erickson]

Hi All,

I'm interested in contributing a fix for the following issue:

https://issues.gradle.org/browse/GRADLE-3220

In my original investigation, I found that it looks like this problem is only present when using the Groovy joint compiler.  Using the same annotation processor for Java compilation worked as expected with no classpath contamination.

Can someone give me some pointers of where I should start looking?  Is comparing the source for JavaCompile and GroovyCompile a good place to start?

Thanks

-Will

[Daz DeBoer]

Hi Will

Thanks for offering to help. According to Luke's analysis, the difference between JavaCompile and GroovyCompile is more likely to be due to whether or not we're forking the compilation with a daemon compiler. By default, we _do_ fork the compilation for GroovyCompile, but not for JavaCompile.

It would be worth investigating whether you get the same classpath contamination when using JavaCompile with options.fork=true.

To understand how the Classloaders are configured for a daemon compiler, you'll want to take a look at DaemonGroovyCompiler and DaemonJavaCompiler: these classes provide the classpath for the compiler daemon, as well as any packages that should be shared between the compiler daemon and the compiler itself.  Starting the daemon process is then performed by CompilerDaemonStarter.

Hope this helps you investigate further.

cheers

Daz

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/a693c877-8d70-4a9e-8426-32670e0ba51f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Darrell (Daz) DeBoer

http://www.gradleware.com

[Will Erickson]

Hi Daz,

Thanks for the explanation.

I've been able to confirm that I can reproduce the problem with java compilations if I enable forking.

However, based on what you've said, I've also been able to confirm that I can work around this problem in groovy builds if I disable forking, by doing the following:

compileGroovy {

    groovyOptions.fork = false

}

I think with this workaround, the urgency around getting this fixed for Groovy Dagger builds has dwindled.

-Will

[Daz DeBoer]

On Sun, Jan 11, 2015 at 3:50 PM, Will Erickson <weri...@gmail.com> wrote:

Hi Daz,

Thanks for the explanation.

I've been able to confirm that I can reproduce the problem with java compilations if I enable forking.

However, based on what you've said, I've also been able to confirm that I can work around this problem in groovy builds if I disable forking, by doing the following:

compileGroovy {

    groovyOptions.fork = false

}

 

Thanks for letting us know, Will. I've added your comment to the Jira issue.

Of course, if you're still interested in contributing a real fix, you'd be most welcome :).

Daz

 

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/ae95807b-66a4-4757-9cfe-cafbdcdb8533%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.