GMaven Migration

Migrating configurations

Switching from GMaven requires some changes to your confugration, although the configuration is very similar. The Examples page has many popular use cases. The most common migrations are documented below.

Compiling

For many users, you replace a configuration like this one

<project>
  <properties>
    <gmaven.version>1.5</gmaven.version>
    <gmaven.providerVersion>2.0</gmaven.providerVersion>
    <groovy.version>4.0.6</groovy.version>
  </properties>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.gmaven</groupId>
        <artifactId>gmaven-plugin</artifactId>
        <version>1.5</version>
        <configuration>
          <providerSelection>2.0</providerSelection>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>generateStubs</goal>
              <goal>compile</goal>
              <goal>generateTestStubs</goal>
              <goal>testCompile</goal>
            </goals>
          </execution>
        </executions>

        <!-- some projects might also override the Groovy version with something like below -->
        <dependencies>
          <dependency>
            <groupId>org.codehaus.gmaven.runtime</groupId>
            <artifactId>gmaven-runtime-2.0</artifactId>
            <version>1.5</version>
            <exclusions>
              <exclusion>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-all</artifactId>
              </exclusion>
            </exclusions>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <version>${groovy.version}</version>
            <type>pom</type>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>
</project>

With the one documented here.

Running scripts

For many users, you replace a configuration like this one

<build>
  <plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.5</version>
    <configuration>
      <source>println 'Hi!'</source>
      <providerSelection>2.0</providerSelection>
    </configuration>
  </plugin>
</build>

With the one documented here.

FAQ for users migrating from GMaven

A special welcome to you! I hope you find that this plugin meets your needs. Here's the answers to some questions you might have about your migration.

What does GMavenPlus provide that GMaven doesn't?

• Uses whatever version of Groovy your project does (this was possible with GMaven, just not as straight-foward -- you needed to override the plugin dependencies)
• Access to the groovydoc tool (this might make stub generation unneeded for you if you're not mixing Groovy and Java)
• Some additional configuration options (including the option to use invokedynamic)

What's not in GMavenPlus that was in GMaven?

Below are the items I don't plan on implementing at this time. However, if these features are important to anyone (or my assumptions are flawed), I'll gladly reconsider.

• The GroovyMojo (this is unnecessary since you can compile your mojo like any other Groovy class when you use Java 5 annotations)
• The stack trace sanitization feature (this should be configurable with Groovy's debug property instead)
• gmaven-archetypes and gmaven-examples (I thought the usage is so simple that between the Maven site and the integration tests these aren't really needed.)
• The groovy-jar type (I felt it was wrong to change the type just because Groovy was used. Types should be used for what it is, not how it was made. Plus it wouldn't work for polyglot builds.)

Will GMavenPlus fix my stub generation issues?

I've not personally ever run into these issues, but for those that have: Probably not. The method of generating stubs uses classes maintained by the Groovy project, which is also the way GMaven works (except for the 1.5 and 1.6 providers which implement their own stub generation). So if you had problems with it, you'll probably have problems with this as well. If you do encounter issues with stub generation, please drop me a note or raise an issue. I'd be happy to see if it is happening within GMavenPlus (in which case I'll fix it), or if it's not you can create an issue for the Groovy team. Alternatively, you can use the Groovy-Eclipse Compiler Plugin for Maven, which doesn't use stubs.

But which tool is the official one?

Technically, there never was any official (endorsed by Groovy team) plugin for Maven. GMaven was (and still is) very popular because there were no good alternatives at the time. Groovy-Eclipse compile plugin for Maven has become increasingly popular because GMaven was being worked on less and less. The closest thing to an official tool I guess would be groovyc, since it's maintained by the Groovy team. However, it's also worth noting that Groovy itself is built with Gradle.