groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: Are GMavenPlus stubs compiled?
Date Tue, 24 Nov 2015 19:11:42 GMT
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:keeganwitt@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.Winnebeck@windstream.com<mailto:Jason.Winnebeck@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.Winnebeck@windstream.com<mailto:Jason.Winnebeck@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.

Mime
View raw message