groovy / gmavenplus Goto Github PK

Here is a part of pom.xml

 <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <argLine>-XX:-UseSplitVerifier</argLine>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.gmavenplus</groupId>
                <artifactId>gmavenplus-plugin</artifactId>
 <version>1.5</version>
                    <executions>
                        <execution>
                            <goals>
                                <goal>addSources</goal>
                                <goal>addTestSources</goal>
                                <goal>generateStubs</goal>
                                <goal>compile</goal>
                                <goal>testGenerateStubs</goal>
                                <goal>testCompile</goal>
                                <goal>removeStubs</goal>
                                <goal>removeTestStubs</goal>
                            </goals>
                        </execution>
                    </executions>
            </plugin>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <compilerArgs>-XX:-UseSplitVerifier</compilerArgs>
                </configuration>
            </plugin>

and an error:

[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:testCompile (default) on project xxx: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: Expecting a stackmap frame at branch target 19


org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:testCompile (default) on project datalabs-pig: Error occurred while calling a method on a Groovy class from classpath.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:364)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error occurred while calling a method on a Groovy class from classpath.
    at org.codehaus.gmavenplus.mojo.CompileTestsMojo.execute(CompileTestsMojo.java:61)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 23 more
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.gmavenplus.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:118)
    at org.codehaus.gmavenplus.mojo.AbstractCompileMojo.doCompile(AbstractCompileMojo.java:201)
    at org.codehaus.gmavenplus.mojo.CompileTestsMojo.execute(CompileTestsMojo.java:57)
    ... 25 more
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 19

Verify Groovy version supports target bytecode, otherwise will silently default to 1.4 or 1.5. Fixed in 0b06de4.

Having the following Groovy classes:

package test
class A {}

package test
abstract class BaseGeneric<T extends A> {
    T obj
    protected BaseGeneric(T obj) { this.obj = obj }
}

package test
class SubGeneric<B extends A> extends BaseGeneric<B> {
    SubGeneric(B obj) { super(obj) }
}

The compiler produces an error message on Java code generated by GMavenPlus:
test.SubGeneric.java:[16,8] incompatible types: test.A cannot be converted to B

Looking at the generated Java source code for class SubGeneric, we see:

package test;

import java.lang.*;
import java.io.*;
import java.net.*;
import java.util.*;
import groovy.lang.*;
import groovy.util.*;

public class SubGeneric
<B extends test.A>  extends test.BaseGeneric<B>  implements
    groovy.lang.GroovyObject {
;
public SubGeneric
(B obj) {
super ((test.A)null);
}
public  groovy.lang.MetaClass getMetaClass() { return (groovy.lang.MetaClass)null;}
public  void setMetaClass(groovy.lang.MetaClass mc) { }
public  java.lang.Object invokeMethod(java.lang.String method, java.lang.Object arguments) { return null;}
public  java.lang.Object getProperty(java.lang.String property) { return null;}
public  void setProperty(java.lang.String property, java.lang.Object value) { }
}

This cast in the constructor:
super ((test.A)null);

causes a compile error. I really don't understand why, because the generic has to be at least a test.A, so it should theoretically be possible to upcast. But the Java compiler does not like it. It would be OK for him if this was generated instead:

super ((B)null);

Instead having to make sure your <scriptExtensions> match what you declared in your <sources> when using a non-standard Groovy file extensions to get stubs to work, GMavenPlus should detect the extensions from the declared sources and automatically use those.

The maven build-helper plugin allows additional source directories to be configured alas the gmaven plugin does not honor those additional directories. The maven-processor-plugin has an option to honor this setting, perhaps gmavenplus can do the same?

Not really an issue, but I didn't see how to give positive feedback -- this just worked for me. I could not figure out how to get Groovy-Eclipse compiler plugin for Maven to work at all.

Migrated from http://jira.codehaus.org/browse/GMAVENPLUS-22

I haven't done it yet because I haven't figured out how. It'd be really good to do though, since I rely on the suite to discover when things break and I always have to remember to manually test these.

Automatically add generated stubs to the project sources rather than needing to manually specify in the compiler plugin's configuration.

We could extract the logic around handling the discrepancies between the various Groovy versions using reflection into a core module that could be used by other tools (making sure to remove any Maven dependencies). This could improve tool compatibility. Obviously, for tools that tie directly to the Groovyc Ant task, there may not be much benefit to something like this.

I'm leaving as a wishlist for now, if someone has a tool this would be useful for, vote this issue up and we'll tackle it then.

Hi,

Would it be possible to add a feature which would allow calling the execution of a goal of another maven plugin from within a groovy script being executed by GMavenPlus?

For example it could look like this:

<script><![CDATA[
    if(somecontion)
        project.call('resources:resources');
]]></script>

Migrated from http://jira.codehaus.org/browse/GMAVENPLUS-25.

Description
Right now, we're threadsafe because we synchronize the entire Mojo execution. This task is to look into whether we can be smarter about that, and really prove that the plugin is threadsafe. Also it'd be good to know whether we benefit at all from parallel builds after we remove the synchronizing.

Comments
Keegan Witt added a comment - 28/May/14 11:09 PM
One tricky thing that may make this impossible is determining whether the Groovy methods called are threadsafe (especially since that can change between any version).

Migrated from http://jira.codehaus.org/browse/GMAVENPLUS-13.

Joint compilation fails with Groovy 1.9-beta-1 and 1.9-beta-2, but not with 1.9-beta-3. It's puzzling why since the only code that seems to have changed between beta-2 and beta-3 is class generation stuff.

Let the user specify the classpath (compile, test, runtime, or system) into the execute mojo so that they can be used in scripts.

We seem to need the block

if (phase==Phases.SEMANTIC_ANALYSIS) {
    // This appears to be needed to avoid missing imports
    Iterator modules = getAST().getModules().iterator();
    while (modules.hasNext()) {
        ModuleNode module = (ModuleNode) modules.next();
        module.setImportsResolved(false);
    }
}

from GMaven's JavaStubCompilationUnit to properly get all imports in the stubs.

Stub generation doesn't include Javadoc, which is a problem for things like Maven Mojos, which use annotations in the Javadoc to do the Plexus wiring.

Transformations like @Immutable fail with messages like
Not an ASTTransformation: org.codehaus.groovy.transform.ImmutableASTTransformation declared by groovy.lang.Immutable

The following class fails to compile using plugin v 1.0-beta-2

import javax.ws.rs.Produces
import javax.ws.rs.core.MediaType

@Produces(MediaType.APPLICATION_JSON)
class FooResource { }

<dependency>
  <groupId>com.sun.jersey</groupId>
  <artifactId>jersey-client</artifactId>
  <version>1.17.1</version>
</dependency>

[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.0-beta-2:compile (default) on project bugs: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: ClassCastException: attempting to castjar:file:/Users/mchristiansen/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar!/javax/ws/rs/ext/RuntimeDelegate.classtojar:file:/Users/mchristiansen/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar!/javax/ws/rs/ext/RuntimeDelegate.class -> [Help 1]

This feature lets you use this style

<script>${project.basedir}/src/main/resources/groovyScripts/helloWorld.groovy</script>

In addition to the URL style

<script>file:///${project.basedir}/src/main/resources/groovyScripts/helloWorld.groovy</script>

Transformations like @Immutable fail with messages like
Not an ASTTransformation: org.codehaus.groovy.transform.ImmutableASTTransformation declared by groovy.lang.Immutable

Users may want to use GroovyScripts with test dependencies as part of test phase, so we should allow them access to that classpath just in case.

Super POM path references (e.g. ${project.basdir}) don't escape the backslashes used by Windows. This results in code like new File("C:\Users\user\file.txt") instead of new File("C:\\Users\\user\\file.txt").

Plugin only works with Maven 2 because of the org.codehaus.plexus.classworlds.realm.ClassRealm vs org.codehaus.classworlds.ClassRealm issue.

Now that GROOVY-6075 has been fixed, users should be able to choose what bytecode to use.

Hi, I am trying to perform an automated release under Teamcity of a java 8/groovy project with maven 2.2.1. I have one module called B who is a java only jar module and a module A who is a groovy only module that depends on B module.
When I run mvn -U release:prepare --batch-mode -e locally all is ok and the release get prepared but when I try to run in my teamcity environment I get the following error:

[INFO] [INFO] Using Groovy 2.3.9 to perform compile.
[INFO] [INFO] Error occurred while calling a method on a Groovy class from classpath.
[INFO] com/a/b/c/XXX : Unsupported major.minor version 52.0

Gmavenplus plugin config is:

   <plugin>
            <groupId>org.codehaus.gmavenplus</groupId>
            <artifactId>gmavenplus-plugin</artifactId>
            <version>1.5</version>
            <executions>
                <execution>
                    <goals>
                        <goal>addSources</goal>
                        <goal>addTestSources</goal>
                        <goal>compile</goal>
                        <goal>testCompile</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <targetBytecode>1.8</targetBytecode>
                <verbose>true</verbose>
            </configuration>
        </plugin>

  <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>2.3.9</version>
        <exclusions>
            <exclusion>
                <groupId>javax.servlet</groupId>
                <artifactId>jsp-api</artifactId>
            </exclusion>
            <exclusion>
                <groupId>javax.servlet</groupId>
                <artifactId>servlet-api</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>jcl-over-slf4j</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Maven compiler config:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.2</version>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
            <fork>true</fork>
            <compilerVersion>1.8</compilerVersion>
            <executable>${JAVA_1_8_HOME}/bin/javac</executable>
            <compilerArguments>
            </compilerArguments>
            <encoding>UTF-8</encoding>
            <optimize>true</optimize>
        </configuration>
    </plugin>

And logs from Teamcity show me that there is and java 6 version in PATH environment variable but maven is being called with java 8.

Why is gmavenplus plugin using java 6 compiler?
Is there anyway to force gmavenplus plugin to run with a certain JVM?

Since version 1.2 (specifically commit 49f8cb6caf4a45a92b2511119def97de3eb17f87), GMavenPlus hasn't allowed the use of Indy back to when it was first introduced (2.0.0-beta-3), and instead was looking for version 2.1.0-beta-3 (which doesn't exist), with the net effect of forcing users to use version 2.1.0-rc-1 or newer.

My sincerest thanks to Pascal for pointing out my goof.

Stub generation doesn't work for Groovy < 1.8.2

I have a script

<script><![CDATA[
   def ant = new AntBuilder()
   ant.echo('Copying distrib!')
   ant.scp(
      file: '...'
      , todir: '...'
      , verbose: true
      , trust: true
      , keyfile: '${user.home}/.ssh/rsa_2048.ppk'
   )
   ant.echo('distrib complete')
]]></script>

and its failed on Windows with error message:

Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:execute (default) on project bundles: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: startup failed:
[ERROR] Script1.groovy: 9: unexpected char: '' @ line 9, column 47.
[ERROR] , keyfile: 'C:\Users\ssh
[ERROR] ^

Because ${user.home} contains '' characters. I'm not sure this is GMavenPlus issue.

@keeganwitt

I'm interested in using the execute script feature (https://github.com/groovy/GMavenPlus/wiki/Examples#execute-scripts).

What I'd like to know is, if it's possible to execute the script in Maven's generate-resources lifecycle phase?

Groovy versions before 1.8.2 don't output stub files. No exceptions are being thrown, the Groovy classes just aren't outputting any files.

Test mojos should load the project's test dependencies onto the classpath rather than just the compile dependencies.

Groovydoc doesn't work for Groovy < 1.6.2

I'm having difficulty generating groovy documentation for my project.

When I run mvn gplus:groovydoc from the command line the documentation is generated as expected. However, when I attempt to generate the documentation as part of the prepare-package Maven lifecycle, the documentation is generated without any of required content (i.e., the method signatures are there, but the documentation describing the methods is missing).

Snippets from my pom.xml file

    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.gmavenplus</groupId>
                <artifactId>gmavenplus-plugin</artifactId>
                <version>1.0-beta-3</version>
                <executions>
                    <execution>
                        <id>compilecode</id>
                        <goals>
                            <goal>generateStubs</goal>
                            <goal>compile</goal>
                            <goal>testGenerateStubs</goal>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>groovydoc</id>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>groovydoc</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
...
      </plugins>
...
 </build>

The idea here, is to prepare the groovy documentation using Maven's prepare-package phase, and then during the package phase bundle up the docs into a jar file by using the maven-jar-plugin

           <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                        <configuration>
                            <classifier>javadoc</classifier>
                            <classesDirectory>${project.build.directory}/gapidocs</classesDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Plugin does not work with JDK <= 1.4

The stub generation phases do not seem to produce java classes that include the structural changes made by AstTransformations.

class DelegatingMap <K, V> implements Map<K, V> {
@DeleGate Map<K, V> map = new HashMap<>()
}

error: DelegatingMap is not abstract and does not override abstract method entrySet() in Map

Built with version 1.0-beta-2 and groovy 2.1.6 indy

Migrated from http://jira.codehaus.org/browse/GMAVENPLUS-33.

Description
I just realized some goals don't follow the naming convention (the mojo got renamed, but not the goal – I have no idea how I overlooked this so long). To make them consistent, I'd rename
testGenerateStubs -> generateTestStubs
testCompile -> compileTests
testGroovydoc -> groovydocTests
Despite the inconsistency, I'm hesitant to make this change now, since it'd mean folks would have to edit their pom after upgrade to get things working again. The only way I could avoid that is to extend the existing mojos that just make calls to their parent, and one class would have the old goal name, one with new. This would appear to the user as a clone, not an alias, and so would probably just cause more confusion.
I opened this Jira to collect feedback.

Comments
Keegan Witt added a comment - 07/Oct/14 11:31 PM
Actually, I'm warming up to the idea of extending the class as a means of deprecation. The @deprecated Javadoc tag makes it clear users should migrate off the old name, while not actually breaking anything. It's slightly ugly, but it has the advantage of satisfying my meticulous nature while preserving backwards compatibility.
However, now I'm thinking that maybe I should have followed GMaven's convention to begin with (that is, having test in front of the regular goal name). This would match the pattern used by Maven Compiler Plugin, Maven Javadoc Plugin, and Maven Resources Plugin. If I went down that path, it'd mean renaming
addTestSources -> testAddSources
addTestStubSources -> testAddStubSources
removeTestStubs -> testRemoveStubs

Keegan Witt added a comment - 08/Oct/14 7:57 AM
One downside to the deprecation idea would be for m2eclipse users. m2eclipse would need to map both the new and deprecated goals (maybe just ignoring deprecated goals) to prevent errors from popping up.

Jason Winnebeck added a comment - 20/Oct/14 12:34 PM
As a user, I've never noticed the inconsistency. The "addTestSources" reads better to me than "testAddSources". It also doesn't matter much to me whether or not the goals have any consistent relationship with those in other plugins. I've configured a few (3-5) projects with this plugin, and in all cases what I do is go onto the documentation wiki and copy the example execution with all of the goals then just comment out the ones I need. So from that perspective, as long as the goal's name clearly notes what it does, then I'm happy. From my perspective there's no benefit to an arbitrary name change that could break compatibility when updating the plugin.

Keegan Witt added a comment - 24/Oct/14 11:55 AM
Fair enough, and thanks for the feedback. I agree, the benefit to the end-user would be marginal. I just wish I had noticed this while it was still beta, a breaking change would have been more tolerable then. I'll mark this as a "maybe someday" and if for some reason I make a bunch of breaking changes, this can be yet another one (though probably that'll never happen).

The following source files are without license headers.
GMavenPlus-1.5/src/main/java/org/codehaus/gmavenplus/plexus/AbstractIncludeProjectDependenciesComponentConfigurator.java
Please, confirm the licensing of code and/or content/s, and add license headers
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification
Thanks in advance
Regards

Improve the performance of ReflectionUtils by implementing the caching as Spring did in SPR-11882. While we're at it, we should also grab the b4095c3e1d61fc7279e6b2ca105ec60c3cd7128c and 192462902ef3d97c0b6684d467c7d2023ecd5be1 changes.

I tried GMavenPlus 1.5 as a migration away from the now dead Groovy Eclipse Compiler. I keep all my sources, both Java and Groovy, in /src/main/java (I often switch a file from Java to Groovy or back again depending on what it does).

My GMavenPlus compilation fails. The Java classes that depend on Groovy classes cannot find the class files (or stubs or whatever).

Way up near the top I see:
[INFO] --- gmavenplus-plugin:1.5:generateStubs (default) @ hatch-api ---
[INFO] No sources specified for stub generation. Skipping.

My guess is that stub generation is looking in /src/main/groovy for Groovy classes.

I'm also guessing there's an easy way to configure this, but I don't know enough about Maven mojos. I looked through the code, but I couldn't figure out how to specify the source path.

I tried

                <plugin>
                    <groupId>org.codehaus.gmavenplus</groupId>
                    <artifactId>gmavenplus-plugin</artifactId>
                    <version>1.5</version>
                    <configuration>
                        <sources>
                            <source>src/main/java</source>
                        </sources>
                    </configuration>
                                       etc..

but I got

[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:addSources (default) on project hatch-api:
Unable to parse configuration of mojo org.codehaus.gmavenplus:gmavenplus-plugin:1.5:addSources for parameter source: Can
not find default setter in class org.apache.maven.shared.model.fileset.FileSet -> [Help 1]

Is there a way to do this?

PS, thanks for working on this project. Now that GEC is dead, I have to either use GMavenPlus, or migrate all my projects to Gradle, which is a bit of work...

Following dependency:

    <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>2.2.0</version>
        <scope>compile</scope>
        <classifier>indy</classifier>
    </dependency>

gives the following build error:

[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.0-beta-3:compile (default) on project markdown-doc-lib: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: java/lang/invoke/CallSite: java.lang.invoke.CallSite -> [Help 1]

If I remove the indy it builds OK.

My plugin specification looks like this:

        <plugin>
            <groupId>org.codehaus.gmavenplus</groupId>
            <artifactId>gmavenplus-plugin</artifactId>
            <version>1.0-beta-3</version>
            <executions>
                <execution>
                    <goals>
                        <goal>compile</goal>
                        <goal>testCompile</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <invokeDynamic>true</invokeDynamic>
            </configuration>
        </plugin>

Regards,
Tommy Svensson

The constructor currently being called by the compile mojos (in the abstract class) doesn't exist until 1.6.0. This obviously causes the mojo to fail.

In a multimodule project with mixed java/groovy sources I'd like to generate aggregated javadocs in the root project (for site generation) as well as javadoc jars in the individual subprojects (because you cannot deploy anything to Maven Central without it).

• So far I use the gplus:generateStubs goal before running the maven:javadoc plugin, but sadly gplus:generateStubs loses all the original javadocs of the Groovy sources (probably a Groovy problem)
• I considered using the gplus:groovydoc goal, but this has no "aggregate" mode like maven:javadoc has and I neither detected an option to generate a jar file from the javadocs

It would be great if any of the two issues could be improved. Or did I miss something?

Support specifying a jdk via the maven-toolchains-plugin

After setting up a toolchain for the Java 8 jdk, I got a build failure. I'd like to specify which java to use per module for my complicated build so I can invoke maven once from a parent. When I tried to do so, I got the below error. Looks like gmaven-plus was invoked using the java specified by JAVA_HOME environment variable, or whatever was on my path.

[INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ my-project ---
[INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/java-8-oracle]
[INFO] No sources to compile
[INFO]
[INFO] --- gmavenplus-plugin:1.5:testCompile (default) @ my-project ---
[INFO] Using Groovy 2.4.1 to perform testCompile.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.950s (Wall Clock)
[INFO] Finished at: Tue Jul 28 11:43:59 PDT 2015
[INFO] Final Memory: 10M/239M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:testCompile (default) on project my-project: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: com/company/project/SomeClass : Unsupported major.minor version 52.0 -> [Help 1]

Add new configuration options to support GROOVY-7423 (JEP 118: Access to Parameter Names at Runtime).