You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "Winnebeck, Jason" <Ja...@windstream.com> on 2015/11/24 14:46:18 UTC

Are GMavenPlus stubs compiled?

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<ma...@windstream.com> | windstreambusiness.com
o: 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.

RE: Are GMavenPlus stubs compiled?

Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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 <Ja...@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<ma...@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.


Re: Are GMavenPlus stubs compiled?

Posted by Keegan Witt <ke...@gmail.com>.
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> 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 | windstreambusiness.com
>
> o: 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.
>