groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Boekhold <boekh...@gmx.com>
Subject RE: GMavenPlus or groovy-eclipse-compiler?
Date Mon, 21 Sep 2015 16:10:27 GMT
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> 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 
> <boekhold@gmx.com<mailto:boekhold@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.

Mime
View raw message