You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Maarten Boekhold <bo...@gmx.com> on 2015/09/21 07:20:02 UTC
GMavenPlus or groovy-eclipse-compiler?
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
Re: GMavenPlus or groovy-eclipse-compiler?
Posted by Marc Paquette <ma...@mac.com>.
First, Keegan has written nice explanations about this, in case you haven’t got that yet : https://github.com/groovy/GMavenPlus/wiki/Usage <https://github.com/groovy/GMavenPlus/wiki/Usage>
These goals, generateStubs and testGenerateStubs are bound to the `compile` maven phase and `install` phase depends on `compile`, so yes they will be executed provided they are listed as goals in the configuration of gmavenplus-plugin.
Maven phases are part of the lifecycle : Maven – Introduction to the Build Lifecycle <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB0QFjAAahUKEwiV_Ymr1IrIAhXIGj4KHSErBEw&url=https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html&usg=AFQjCNEIvKCYlDOtaHgA_xAMHgn_z6C3uQ>; the default lifecycle is documented here : https://maven.apache.org/ref/3.3.3/maven-core/lifecycles.html <https://maven.apache.org/ref/3.3.3/maven-core/lifecycles.html>.
Hope that helps,
Marc
> Le 2015-09-22 à 03:46, Maarten Boekhold <bo...@gmx.com> a écrit :
>
> Hi,
>
> Showing of my "not being a maven expert" here I suppose.... normally I just run "mvn clean install". Will that automatically run "generateStubs" (and "testGenerateStubs")? Or do I need to do something special for that to happen?
>
> Maarten
>
> On 2015-09-21 23:08, Winnebeck, Jason wrote:
>> 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, andyou 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:boekhold@gmx.com <ma...@gmx.com>]
>> Sent: Monday, September 21, 2015 12:10 PM
>> To: users@groovy.incubator.apache.org <ma...@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.Winnebeck@windstream.com <ma...@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:keeganwitt@gmail.com <ma...@gmail.com>]
>> Sent: Monday, September 21, 2015 9:32 AM
>> To: users@groovy.incubator.apache.org <ma...@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 <boekhold@gmx.com <ma...@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.
>
>
Re: GMavenPlus or groovy-eclipse-compiler?
Posted by Maarten Boekhold <bo...@gmx.com>.
Hi,
Showing of my "not being a maven expert" here I suppose.... normally I
just run "mvn clean install". Will that automatically run
"generateStubs" (and "testGenerateStubs")? Or do I need to do something
special for that to happen?
Maarten
On 2015-09-21 23:08, Winnebeck, Jason wrote:
>
> 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:boekhold@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.Winnebeck@windstream.com
> <ma...@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:keeganwitt@gmail.com]
> *Sent:* Monday, September 21, 2015 9:32 AM
> *To:* users@groovy.incubator.apache.org
> <ma...@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
> <boekhold@gmx.com <ma...@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.
>
RE: GMavenPlus or groovy-eclipse-compiler?
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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:boekhold@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" <Ja...@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:keeganwitt@gmail.com]
Sent: Monday, September 21, 2015 9:32 AM
To: users@groovy.incubator.apache.org<ma...@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 <bo...@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.
RE: GMavenPlus or groovy-eclipse-compiler?
Posted by Maarten Boekhold <bo...@gmx.com>.
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"
<Ja...@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:keeganwitt@gmail.com]
> Sent: Monday, September 21, 2015 9:32 AM
> To: 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
> <bo...@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.
RE: GMavenPlus or groovy-eclipse-compiler?
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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:keeganwitt@gmail.com]
Sent: Monday, September 21, 2015 9:32 AM
To: 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 <bo...@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.
Re: GMavenPlus or groovy-eclipse-compiler?
Posted by Keegan Witt <ke...@gmail.com>.
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. 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 <bo...@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
>
>
>