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 <boekh...@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:boekh...@gmx.com <mailto:boekh...@gmx.com>] 
>> Sent: Monday, September 21, 2015 12:10 PM
>> To: users@groovy.incubator.apache.org 
>> <mailto: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 
>> <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.
> 
> 

Reply via email to