[GRADLE-1909] Problem compiling a Groovy project when a Groovy class from src/main/groovy imports a Java nested interface in src/main/java Created: 10/Nov/11  Updated: 23/Jan/13  Resolved: 23/Jan/13

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-5
Fix Version/s: None

Type: Bug
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Not A Bug Votes: 3

Attachments: Zip Archive GRADLE-1909.zip    

 Description   

Consider the attached project.

It applies 'groovy' plugin and has the following classes:

  • src/main/java/testa/TestA.java: a Java class with a nested interface IA
  • src/main/groovy/testb/TestB.groovy: a Groovy class which implements interface TestA.IA

Do "gradle clean assemble" on the project: the result is:

[ant:groovyc] org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
[ant:groovyc] D:\test-gradle3\src\main\groovy\testb\TestB.groovy: 3: unable to resolve class testa.TestA.IA
[ant:groovyc] @ line 3, column 1.
[ant:groovyc] import testa.TestA.IA
[ant:groovyc] ^
[ant:groovyc]
[ant:groovyc] 1 error
[ant:groovyc]

Now, move src/main/java/testa package to src/main/groovy and retry "gradle clean assemble". It then succeed!

As of:
http://forums.gradle.org/gradle/topics/groovy_plugin_and_mixed_groovy_java_code
I would expect Gradle to build this project correctly without needing to move TestA to src/main/groovy.

 Comments   
Comment by Mauro Molinari [ 20/Jul/12 ]

Any hint on this?

Comment by Mauro Molinari [ 27/Sep/12 ]

Sorry for insisting :-P
Any idea on why this happens? This is causing some troubles to us, especially on some complex project configurations that involve Java source code, Groovy source code and some code that must be shared between the Java compiler, the Groovy compiler classpath and the GWT JavaScript compiler.
I have put a dirty workaround in my build.gradle file that "redirects" all Java source dirs to the Groovy source dirs, but I have to maintain this unless I try to find some other even deeper workaround.

Comment by Wolfgang Häfelinger [ 27/Oct/12 ]

I downloaded GRADLE-1909.zip on my local machine and tried 'gradle clean assemble'. It worked out-of-the-box, as expected:

geronimo@lhasa:~/Downloads/GRADLE-1909
$ gradle clean assemble
:clean UP-TO-DATE
:compileJava
:compileGroovy
:processResources UP-TO-DATE
:classes
:jar
:assemble

BUILD SUCCESSFUL

Total time: 9.618 secs

Comment by Mauro Molinari [ 28/Oct/12 ]

Hmmm... this is a mystery... I'm 100% sure this test case gave problems and I prepared it after I was encountering this problem on a production project (as reported in the forum thread, too). The strange thing is that I can't reproduce now even with Gradle 1.0-milestone-5 (the version I reported the issue against). I'm using the wrapper any maybe I was using it when I opened this bug, too. May something have changed on how the wrapper sets up its environment? I can't explain in another way... I'm sure I had not dreamt about this problem!

Feel free to close this issue now. I will report back if I encounter it again.

Comment by Wolfgang Häfelinger [ 28/Oct/12 ]

> I can't explain in another way... I'm sure I had not dreamt about this problem!
I'm pretty sure that your initial problem was/is related to caching. Perhaps your removed the offending "testa.TestA.IA,class" file somehow and Gradle did just NOT recreate it because the corresponding *.java has not been changed? Not sure either, but I'm constantly fighting with caching problems. I personally would like to see all "optimizations" turned off by default.

Comment by Luke Daley [ 23/Jan/13 ]

Seems like this is no longer an issue.

Generated at Wed Jun 30 12:07:38 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.