It worked fine for me after that, although I suspect it may cause problems in other area, like java/groovy seamless integration.

The previous workaround, as expected, works fine until you have java classes that reference groovy classes. In that case, a full recompile would break with class not found on the depended on groovy classes. I have in that case to separately compile groovy files (first) and java files, and this could not work well in some cases (java class references goovy class which references another project java class, for example). So, this is unrealistic for real world project with mix and matches of java and groovy sources.

After further investigations, I have found that actually the problem is more on a strange behavior of the java compiler for groovy generated classes.

If a groovy class, say Hello.groovy has been modified lately, the following compilation steps take place:
1) generation of Hello.java from Hello.groovy
2) javac compilation to Hello.class from Hello.java
3) groovyc compilation to Hello.class from Hello.groovy, overriding the previous dummy Hello.class

So, the first time, we obtain the correct Hello.class

If the compilation process is launched again on unmodified Hello.groovy, steps one and three are skipped, as expected, but step two is still executed, resulting in the dummy Hello.class to replace the correct one. It seems, that when a java source is resulting from source generation, it is systematically added to the compilation list.

thanks for shedding light on this. Any idea when 7.0.2 is to be expected?