groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: GMavenPlus or groovy-eclipse-compiler?
Date Mon, 21 Sep 2015 13:32:22 GMT
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 <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
>
>
>

Mime
View raw message