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 Tue, 22 Sep 2015 07:46:00 GMT
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 
> <mailto: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
>     <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
>     <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