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. > >