You have to call the generateStubs goal in the GMavenPlus plugin if
you want stubs. You only need to generate stubs if you have Java and
Groovy within the *same* project, *and* you have Java code referencing
Groovy classes. If your Java code is in a separately compiled module
(i.e. Groovy module A generates A.jar used by Java module B depending
on A), or if the Java code does not reference Groovy classes (Groovy
calling Java is fine), then you do not need stubs.
The reason why stubs are needed are because the Java compiler cannot
read Groovy source files. The stub is a Java version of the Groovy
class with none of the code within the methods so that javac can call
against it. In the case of separate modules, javac can use the .class
files generated by Groovy.
Jason
*From:*Maarten Boekhold [mailto:boekh...@gmx.com]
*Sent:* Monday, September 21, 2015 12:10 PM
*To:* users@groovy.incubator.apache.org
*Subject:* RE: GMavenPlus or groovy-eclipse-compiler?
Hi, those stubs you mention are created automatically, right? I mean
I do not have to do anything do let java call groovy and vice versa?
And is there any impact on packaging the compiled result?
Maarten
On 21 September 2015 18:08:57 "Winnebeck, Jason"
<jason.winneb...@windstream.com
<mailto:jason.winneb...@windstream.com>> wrote:
Actually I agree with the compile difference issues. We used
Groovy-Eclipse for the short time period after GMaven was
deprecated but before GMavenPlus was available. It was a horrible
experience. The joint compilation was nice, but the compiler
results were always different, and there was always significant
lag in Groovy releases. Specifically, we had major issues
constantly with static compiler where code would compile under
groovyc/intellij but not compile under groovy-eclipse in Maven, so
we had check-ins causing compiler errors all the time.
Additionally, it was also easy to mismatch Groovy version to the
compiler version, which would cause even more problems. Switching
to GMavenPlus solved all of our problems as it uses mainline
Groovy to compile, which is also what IntelliJ uses, and it uses
any Groovy version as soon as it comes out, and the Groovy version
defined in Maven so there’s no risk of a mismatch.
The one and only benefit that existed to the Groovy-Eclipse
compiler was that stubs were not needed.
Jason
*From:*Keegan Witt [mailto:keeganw...@gmail.com]
*Sent:* Monday, September 21, 2015 9:32 AM
*To:* users@groovy.incubator.apache.org
<mailto:users@groovy.incubator.apache.org>
*Subject:* Re: GMavenPlus or groovy-eclipse-compiler?
Well, at the moment, we unfortunately don't have a regular
maintainer for Groovy-Eclipse. But I plan to update
Groovy-Eclipse myself with support for GMavenPlus (so you don't
have to do the custom lifecycle mapping thing) in the coming weeks
(should be an easy code change, I just need the time to test it --
I talked about doing this with Andrew Eisenberg quite a while
back, but it fell off my radar, sorry). In the mean time, I'm
pretty sure what you did should be fine.
Thanks for mentioning 2.4.4 issue (as an IntelliJ guy, I tend not
to notice). If I get some free time, I'll also take a look at
updating for Groovy 2.4.4/2.4.5. <http://2.4.5.> I'm not sure
offhand how much work that'll be (if it doesn't suck too much of
my life away, I'll keep it updated from now on until we find
someone with more Eclipse compiler expertise to take over proper
maintenance of the project).
It's true Groovy-Eclipse uses forked classes. In some ways
though, they have more functionality than the official classes (in
fact we'd talked about merging some of this with upstream Groovy
after we finish the ANTLR 4 stuff -- currently considering for
whenever we do Groovy 3). But I was never comfortable using them
because there were occasional differences I've seen in what would
compile in Groovy-Eclipse vs what would compile with
groovyc/GMavenPlus/Gradle. You can see the forked classes for
Groovy 2.4 here
<https://github.com/groovy/groovy-eclipse/tree/master/base/org.codehaus.groovy24/src/org/codehaus/groovy>.
But I think the reason most folks recommend something like
GMavenPlus over Groovy-Eclipse isn't because there are minor
compilation differences, but because there are things
<https://github.com/groovy/GMavenPlus/wiki/Choosing-Your-Build-Tool#groovy-eclipse-compiler-plugin-for-maven>
you can't do in Groovy-eclipse (e.g. Groovydoc, invokedynamic,
configuration scripts).
Short answer: I don't like labeling my advice the "official" word
(since as the GMavenPlus author, my opinion may appear biased),
but I think the community consensus concurs with me. I'd suggest
using GMavenPlus with the lifecycle mapping as you have done, then
remove the mapping once I patch Groovy-Eclipse.
-Keegan
On Mon, Sep 21, 2015 at 1:20 AM, Maarten Boekhold
<boekh...@gmx.com <mailto:boekh...@gmx.com>> wrote:
Hi all,
I'm looking on some feedback on which maven plugin is currently
preferred/recommended: GMavenPlus or groovy-eclipse-compiler?
As far as I know, development on the groovy-eclipse-compiler has
stalled somewhat, and currently it does not support Groovy 2.4.4.
Also, it's using its own groovy compiler, not the official one.
GMavenPlus on the other hand seems to lack Eclipse M2E support. If
you import a maven project that uses GMavenPlus into Eclipse you
get lots of these annoying "plugin execution not covered by
lifecycle" errors.
On a project that currently uses the groovy-eclipse compiler I did
a small test to replace it with GMavenPlus and I managed to get
rid of those errors by including the following in my pom.xml, but
I'm not sure that doesn't introduce any issues down the road (I'm
not familiar at all with mapping Eclipse lifecycle events to maven
goals):
<*plugin*>
<*groupId*>org.eclipse.m2e</*groupId*>
<*artifactId*>lifecycle-mapping</*artifactId*>
<*version*>1.0.0</*version*>
<*configuration*>
<*lifecycleMappingMetadata*>
<*pluginExecutions*>
<*pluginExecution*>
<*pluginExecutionFilter*>
<*groupId*>
org.codehaus.gmavenplus
</*groupId*>
<*artifactId*>
gmavenplus-plugin
</*artifactId*>
<*versionRange*>
[1.5,)
</*versionRange*>
<*goals*>
<*goal*>addSources</*goal*>
<*goal*>addTestSources</*goal*>
<*goal*>compile</*goal*>
<*goal*>generateStubs</*goal*>
<*goal*>removeStubs</*goal*>
<*goal*>removeTestStubs</*goal*>
<*goal*>testCompile</*goal*>
<*goal*>
testGenerateStubs
</*goal*>
</*goals*>
</*pluginExecutionFilter*>
<*action*>
<*ignore*></*ignore*>
</*action*>
</*pluginExecution*>
</*pluginExecutions*>
</*lifecycleMappingMetadata*>
</*configuration*>
</*plugin*>
Is there any "official" advise on this topic?
Maarten
------------------------------------------------------------------------
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.
