I just assumed this was a side-effect of 
https://issues.apache.org/jira/browse/GROOVY-7366. I don’t think import without 
fully qualified class names is a good thing. I’ve never seen it before, and I 
tested for a fact it doesn’t work in Java. Even if com.foo.X and com.foo.Y are 
in the same package, you can’t “import static Y.*” inside of X.java, you have 
to still “import static com.foo.Y.*” I didn’t verify this, but I assumed Groovy 
was copying over the import exactly as-is without fully qualifying it. I 
considered it bad style anyway, and IntelliJ doesn’t generate imports that way 
(you have to hand-enter it), so I didn’t dwell on the bug in Groovy itself.

What concerned me that I mis-configured gmavenplus and I was wasting time 
compiling stubs or risking the stubs getting into the output jar, because from 
my understanding javac only needs the stubs on the sourcepath to use as 
reference and not requiring them to be actually compiled. Since IntelliJ worked 
I assumed that it was avoiding actual javac compilation of the stubs (since 
that particular stub being compiled was never referenced from any Java code). 
As far as I know IntelliJ uses the exact Groovy jar I specify in my Maven POM – 
my only evidence of this though is that when I run/build scripts I know for 
certain it uses the project’s Groovy (which comes from the POM), and also I 
encounter static compilation errors a lot and upgrading groovy fixes those 
errors, which would not be possible were IDEA compiling with a bundled Groovy.

Jason

From: Keegan Witt [mailto:keeganw...@gmail.com]
Sent: Tuesday, November 24, 2015 1:29 PM
To: users@groovy.incubator.apache.org
Subject: Re: Are GMavenPlus stubs compiled?

Yes, the stubs are compiled together with the Java sources so that Javac has 
classes for the Groovy sources to compile against.

If I recall correctly, there were some bugs both introduced and fixed in 
Groovy's stub generation.  It probably works in IntelliJ because I believe they 
use a bundled version of Groovy to do the compilation, whereas GMavenPlus uses 
the version of Groovy you declare as a dependency to do the compilation.  If 
you are not able to reproduce the problem in Gradle or Groovyc Ant, then I'm 
mistaken and it may be a GMavenPlus bug.  If I get time tonight I'll try to 
experiment with that version of Groovy and see whether this seems to be the 
case.  Otherwise, I'd check the Jira release notes for fixes to stubs with 
imports and try a different Groovy version.

-Keegan

On Tue, Nov 24, 2015 at 8:46 AM, Winnebeck, Jason 
<jason.winneb...@windstream.com<mailto:jason.winneb...@windstream.com>> wrote:
Our team just moved from Groovy 2.3.3 to 2.3.5. In our code there was a star 
import that referenced a class in the same package (import X.* instead of 
import com.foo.bar.X.*). The project compiles from IntelliJ but not from Maven 
(using gmavenplus-plugin 1.2) – the error actually comes from the Java 
compiler, probably Java always needs fully qualified name.

OK, so this is probably a minor bug in Groovy, but I’m not worried about that 
as I can fully qualify the import. What I’m wondering is why javac was trying 
to compile this stub in the first place? The class with the import is a groovy 
class and as far as I can tell is only referenced by other Groovy files. Is it 
typical/expected that Maven compiles all of the stubs with javac? The fact that 
the project builds from a clean source from IntelliJ suggests it’s not strictly 
required that javac runs on that stub.

Jason Winnebeck
Software Engineer III Contractor - IT Software Development | Windstream
600 Willowbrook Office Park, Rochester, NY 14450
jason.winneb...@windstream.com<mailto:jason.winneb...@windstream.com> | 
windstreambusiness.com<http://windstreambusiness.com>
o: 585.794-4585<tel:585.794-4585>

________________________________
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Reply via email to