You're right, but this is a design problem that I'm not sure I have a good answer for. I read the version string from the jar name itself because I wanted to support all versions of Groovy, but there wasn't a reliable way to do this from Groovy's API until 1.6.6. Here was the discussion I originally had, which I summarize in the Javadoc on ClassWrangler's getGroovyVersionString().

Maybe what I could do is try the jar method first, then fall back to calling the Groovy API. Let me give it some more thought.

1. I am not familiar with the Maven plugin system. But maybe it's possible to get a classloader that doesn't have the ${build.outputDirectory} in scope.

2. Why not just calling GroovySystem.getVersion() and InvokerHelper.getVersion() per reflection in this order? Shouldn't it always produce a result? And it's much less code than fiddling with the classpath.

There are a few difficulties.

• There are cases in which InvokerHelper.getVersion() has issues (I've heard GAE is one such case), and GroovySystem.getVersion() isn't available because it's an older version of Groovy. Although in such cases I can fallback to current behavior.
• If for some reason I have to fall back to current behavior, Groovy brought in by an uber jar will still not work correctly (for example, if the uber jar has a version on it, it'll find that version not the Groovy version).
• There's no way to use the Groovy API to tell whether I'm looking at the indy version of Groovy or not. Maybe I'll have to keep track of how I determined the Groovy version and don't do the indy safety check if I wasn't able to use the jar name. Or just give up on the safety check altogether.

The last time I tried using InvokerHelper.getVersion(), it didn't seem to be working for 1.5.0 (just returned an empty string). I'll do some more digging to figure out why.

Another option that comes to mind is parsing the MANIFEST.MF for the Groovy version, but these are often stomped on in uber jars.

OK. Jochen suggested I check for the existancen of org.codehaus.groovy.vmplugin.v7.IndyInterface for my indy safety check. So what I put in place is trying in this order

1. GroovySystem.getVersion()
2. InvokerHelper.getVersion()
3. The old jar name method

There are times when working with old versions of Groovy (like 1.5.0) that I won't be able to detect the Groovy version when it's in an uber jar. But I don't see that I have any options there. For any recent version of Groovy (1.6.6 or newer), it should work without issue.

Since this is a change to something pretty core, I want to do some more testing before I release it. But this is a significant defect, without any viable workaround (if you're unlucky enough to have your uber jar before any Groovy jar in your classpath), so I will be releasing it pretty quickly. I deployed a snapshot with this change to Codehaus snapshots. Could you verify that this resolves this issue for you?

Version 1.5-SNAPSHOT works like charm.

Thank you very much.

Hmm. I hadn't considered this particular use case. The ExecuteMojo (which executes scripts) is itself synchronized, so scripts won't be run in parallel and stomp on each other (which is something I think GMaven didn't have). But what can happen is if you have tests and scripts running at the same time (for example), and one or both modify the security manager and/or do system exits, it can interfere with the normal behavior. Unfortunately, I don't think there's any thread-specific security manager configuration in Java. I'm not sure there's any safe way to always do the right thing automatically.

I think this is a bit of an edge case, plus I prefer to avoid changing defaults unless there's a strong argument for doing so. Would it be sufficient for your use case to allow you to opt-out of GMavenPlus's security manager with a new configuration option? Feel free to argue why I should invert the default (if you feel it's appropriate), and to correct me if I'm totally misunderstanding the scenario here.

Ooh, actually I already did that with the allowSystemExits option. The only problem is I set the manager back to what it was at the start of the execution regardless of the setting (which I shouldn't be).

Given that I never did Maven plugin development myself and do not know what is going on internally, I do not really have strong opinion here and I am not in a position to argue
However it really sounds to me like it should be Maven itself protecting itself from System.exit invoked from plugins, not plugin developers care about that.

Anyways, the workaround you are suggesting is good for us so if you could fix GMavenPlus so it does not "restore" security manager in the end when it was told to not change it in the beginning - it should do the trick.
Do you have plans on releasing new version soon?

Many thanks

My release cadence is "when it's needed", but I usually space out releases a bit to give others the opportunity to report issues for the next release (otherwise I'd have a release for nearly every single Jira). My last release was less than a week ago, but I'll release again if it's a substantial issue. Otherwise, I'll release in a month or so. How burdensome would it be to remove the -T option for now?

Could you verify that <allowSystemExits>true</allowSystemExits> in GMavenPlus's <configuration> with the 1.4-SNAPSHOT I just deployed to Codehaus Snapshots resolves your issue?

Yep, build succeeded with that option.
Surely we can wait for the release.

Thanks!

Awesome! Thanks for your feedback!

There are two circumstances under which this change is relevant.

1. When running parallel builds (-T option) with script execution
2. When mixing unit tests that change the security manager and script executions

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

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.

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.

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

Migrated to GitHub.

Works in 1.2, but includes grooid as part of version string. I haven't been able to think of a scenario where this would cause an issue, but I'm officially only supporting grooid in 1.3.

Migrated to GitHub.

Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/local/maven
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.3", arch: "x86_64", family: "mac"

Perhaps this view of the dependencies gives you further details about the setup

[INFO] org.codehaus.griffon.samples:test:jar:0.1.0.SNAPSHOT
[INFO] +- org.codehaus.griffon:griffon-groovy-compile:jar:2.0.0.BETA:provided
[INFO] |  +- org.codehaus.griffon:griffon-core-compile:jar:2.0.0.BETA:provided
[INFO] |  |  \- org.kordamp.jipsy:jipsy:jar:0.4.0:provided
[INFO] |  \- org.kordamp.gipsy:gipsy:jar:0.4.0:provided
[INFO] +- org.codehaus.griffon:griffon-groovy:jar:2.0.0.BETA:compile
[INFO] |  +- org.codehaus.griffon:griffon-core:jar:2.0.0.BETA:runtime
[INFO] |  |  +- javax.inject:javax.inject:jar:1:runtime
[INFO] |  |  \- com.google.code.findbugs:jsr305:jar:2.0.2:runtime
[INFO] |  \- org.codehaus.groovy:groovy-all:jar:2.3.3:runtime
[INFO] +- org.codehaus.griffon:griffon-swing:jar:2.0.0.BETA:compile
[INFO] +- org.codehaus.griffon:griffon-swing-groovy:jar:2.0.0.BETA:runtime
[INFO] +- org.codehaus.griffon:griffon-guice:jar:2.0.0.BETA:runtime
[INFO] |  \- com.google.inject:guice:jar:3.0:runtime
[INFO] |     \- aopalliance:aopalliance:jar:1.0:runtime
[INFO] +- log4j:log4j:jar:1.2.17:runtime
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.5:runtime
[INFO] |  \- org.slf4j:slf4j-api:jar:1.7.5:runtime
[INFO] \- org.codehaus.griffon:griffon-core-test:jar:2.0.0.BETA:test
[INFO]    +- junit:junit:jar:4.11:test
[INFO]    |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO]    \- com.jayway.awaitility:awaitility:jar:1.4.0:test
[INFO]       +- org.hamcrest:hamcrest-library:jar:1.3:test
[INFO]       +- cglib:cglib-nodep:jar:2.2:test
[INFO]       \- org.objenesis:objenesis:jar:1.2:test

User error. The groovy-all dependency exported by griffon-groovy is marked as a runtime dependency. Fixing the pom of griffon-groovy allows gmavenplus to perform the work as expected.

It should be noted that this change will break your build if all the conditions below are met

1. You are using the groovydoc and/or testGroovydoc goal
2. You have specified stylesheetFile
3. You have not specified stylesheetEncoding
4. Your system has a default encoding other than UTF-8
5. The file specified by stylesheetFile contains characters outside the ASCII range

I decided that the chances of this breaking a build are pretty small, and since the new behavior better conforms to the principle of lease surprise, it's an acceptable risk.

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

I've gone back and forth on whether the way GMavenPlus binds predefined variables (with a separate variable for each) vs the way GMaven bound variables (all within a properties variable). Here's what I thought about making this change:

Pros

• Limits possibility of variable name collision by using just 1 variable name
• New variables won't break existing scripts just because of a version upgrade
• Might be a little clearer since the name matches the pom parameter

Cons

• Is a breaking change
• Is more verbose

Since none of the pros seemed compelling enough to make the breaking change to completely switch the binding styles, I decided to allow the user to choose and default to the current behavior.

Migrated to GitHub.

I ended up using profiles to do this. Not as simple as I was hoping for, but it works.

Interestingly, the Clojure plugin has it's own packaging type. I'm not sure why. Maybe one of their devs can explain it to me.

Notably, the Scala, Kotlin, and Jython Maven plugins don't have their own packaging type.

I guess another option would be to leave the feature in, but recommend that it not be used.

Actually it's even possible for an artifact to be a groovy-jar and not contain a single line of Groovy if a user used the custom lifecycle but only used Groovy for testing.

I didn't hear back from Mark, but I've thought a lot about this and I'm still convinced removing this is the right thing to do. It may make the pom more verbose for some, but the ultimate deliverable is the jar, and marking that as anything but a jar isn't right.

I forgot to mention that my reading of the commit messages in the Clojure plugin source code seem to suggest that they used the custom lifecycle for the same reasons that I did, a shorter pom.

Actually, there are methods I'm using internally that also don't work with 5.

I've committed an initial version of the fix. One worry I have is that calling a method on one of the Groovy objects that doesn't take a ClassLloader as an argument will use the current ClassLoader and leak classpaths that way. But when I do

Thread.currentThread().setContextClassLoader(isolatedClassLoader);

it doesn't seem to be able to find the Groovy classes.

I also considered adding a new ClassRealm to the Plexus ClassWorld. The reason I didn't go with that approach is that the world has a realm for each plugin and this isolated ClassRealm would be a top level container. I could prefix the name with the Maven coordinates of the plugin to reduce the chances of a collision between ClassRealm IDs, but this would require either filtering Java or looking it up against a manifest file at runtime. And even if I did that, I think the ClassRealm would continue to exist even after the execution of the plugin, since there's no way to know nothing else will reference that ClassRealm. Maybe there's something I could tie to in the Maven lifecycle to remove the unneeded ClassRealm, but it seemed simpler to just instantiate a new ClassLoader object.

Doing Thread.currentThread().setContextClassLoader(isolatedClassLoader) doesn't work with Class.forName(String className) because the JDK code is

public static Class<?> forName(String className) throws ClassNotFoundException {
    return forName0(className, true, ClassLoader.getClassLoader(Reflection.getCallerClass()));
}

.
So now it's a question of whether to do Thread.currentThread().setContextClassLoader(isolatedClassLoader) in addition to Class.forName(String name, boolean initialize, ClassLoader loader).

OK, after more reading of Groovy code it looks like not calling Thread.currentThread().setContextClassLoader(isolatedClassLoader) results in the parent ClassLoader being the plugin ClassLoader rather than the isolated ClassLoader. This didn't seem to affect the integration tests, but it's probably safer to set it just in case.

I'll take these one at a time.
properties
These are already supported. Unless I'm misunderstanding.
ant
I'm not sure what this would mean in our context. We don't use Ant. Could you explain?
fail
I don't think I can support this the same way GMaven did because I would need to implement a Groovy interface which would mean introducing a hard dependency on Groovy.
log
This is doable, we could bind to Maven's log.

I may be misunderstanding the properties.

In groovy-maven-plugin, you have (see http://groovy.github.io/gmaven/groovy-maven-plugin/execute.html):

<configuration>
          <properties>
            <name>Xenu</name>
          </properties>
          <source>
            println 'Hello ' + properties['name']
          </source>
</configuration>

and default properties:

<configuration>
        <defaults>
          <name>Xenu</name>
        </defaults>
        <source>
          println 'Hello ' + properties['name']
        </source>
</configuration>

which can be overwritten by mvn -Dname=Dave.

This is in addition to the "built-in" variable properties that groovy-maven-plugin that you can refer to:

println "$project.basedir"

This doesn't seem quite the same as the properties support in gmaven+, however I think you could achieve a similar result with appropriate configuration?

ant is described as a pre-configured instance of AntBuilder - enormously useful in scripts to do stuff like:

ant.copy(todir: "${project.build.directory}/css") {
    preservelastmodified : true
    fileset(dir : "${project.basedir}/css") { 
        include(name:"**/*") 
    }
}

For fail, pretty much 100% of the cases I've seen it used, it's really just a method call that throws the appropriate Maven exception to fail the build. No special closure stuff.
Maybe there's a method on the Maven project/session that is already accessible that would do this? Or expose a Mojo/Maven object that has such a method?

Note that all these XML snippets are within the context of GMavenPlus's <plugin> group.

properties
Here's an example of how you'd do that

<configuration>
  <properties>
    <property>
      <name>someProp</name>
      <value>someValue</value>
    </property>
    <property>
      <name>cliProp</name>
      <value>${cliProp}</value>
    </property>
  </properties>
  <scripts>
    <script><![CDATA[
      assert someProp == "someValue"
      assert cliProp == "someValueFromCommandLine"
    ]]></script>
  </scripts>
</configuration>

I did bind these a little different than how GMaven did. GMaven bound things like project by name, and put everything else in a variable called 'properties'. Instead, I bound them all by name (as you can see in the example). If you think that's problematic, let me know.
ant
I'll remind myself how GMaven's does it, specifically for the binding (I used to contribute to GMaven). But maybe it'd work to just do this?

<configuration>
  <scripts>
    <script><![CDATA[
      AntBuilder ant = new AntBuilder()
    ]]></script>
  </scripts>
</configuration>
<dependencies>
  <dependency>
    <groupId>org.apache.ant</groupId>
    <artifactId>ant</artifactId>
    <version>1.9.3</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>

fail
Fail was just a wrapper around Maven's MojoExecutionException. You can call that directly. Here's an example of how you'd do that

<configuration>
  <scripts>
  <script><![CDATA[
    import org.apache.maven.plugin.MojoExecutionException
    if (someCondition) {
      throw new MojoExecutionException("Some error occurred")
    }
  ]]></script>
  </scripts>
</configuration>

log
I'll probably include this in the next release. Thank you for the suggestion.

I've got mixed feelings on the ant suggestion. On the one hand, the example I provided gives a valid workaround and GMavenPlus wouldn't have a dependency on a particular version of Ant. On the other hand, it means more configuration for the user and including dependencies so a user doesn't have to isn't entirely unprecedented (we include Jansi so the shell mojo won't blow up when the user doesn't include it as a dependency). I'm kinda starting to lean towards including it now. Lemme think about it some more.

I've added ant and log to what will be the 1.2 release. I've deployed a snapshot of it, if you'd like to give it a try.

Migrated to GitHub.

gmavenplus-plugin version 1.0
Maven 3.2.1
Java version: 1.7.0_51

I did that on purpose, but your use case seems valid and is making me question that decision. Lemme think about it some more. In the mean time, as a workaround you can do

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <properties>
    <groovyVersion>2.2.1</groovyVersion>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy-all</artifactId>
      <version>${groovyVersion}</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.gmavenplus</groupId>
        <artifactId>gmavenplus-plugin</artifactId>
        <version>1.0</version>
        <executions>
          <execution>
            <goals>
              <goal>testGenerateStubs</goal>
              <goal>testCompile</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <version>${groovyVersion}</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>
</project>

OK. As I'm looking over this, I'm remembering more about why I did it this way. The problem is with the configurators. When I grab the dependencies from the project compile or test classpath, I grab all the dependencies on that classpath. So the concern is one of classpath pollution. If you had a compile dependency on Foo and a test dependency on Bar, and Foo depended on SomeDependency version 1, and Bar depended on SomeDependency version 2, and I just pulled in all the test dependencies, I would compile your main code that uses Foo with version 2 of SomeDependency rather than version 1.

The only way I can think of to avoid this pollution while still looking to your test dependencies for Groovy would be to inspect the URLs of the classpath elements and keep a list of known transitive dependencies of Groovy and only pull Groovy and the transitive dependencies on the list in. But that seemed rather heavy-handed and fragile to me.

I hate how unintuitive my workaround for your use case is, but offhand I can't think of a good way to safely do what you're asking. I'll keep thinking about it, but worst case scenario I'll add the workaround for this to the examples documentation.

Actually, I was wrong about this being an issue with the configurators, the test mojos bring in the test classpath, I just need to remember to check it. I've committed a fix in for this, I'll do a deploy of the snapshot tonight or tomorrow so you can test it.

I've deployed a new snapshot (1.1-SNAPSHOT) on Codehaus Nexus that includes this fix. I'd be shocked if it didn't work for you, but I'd appreciate it if you tried it out before I release it. Make sure you use version 20140228.045602-5 and not one of the older snapshots.

Hi Keegan,

thanks for the prompt fix. Indeed, I was also wondering how maven-compiler-plugin would do it, since it would be the same problem.

I've downloaded and installed locally version 20140228.045602-5. It fails with:

testGenerateStubs failed: A required class was missing while executing org.codehaus.gmavenplus:gmavenplus-plugin:1.1-SNAPSHOT:testGenerateStubs: [Lorg/apache/maven/shared/model/fileset/FileSet;
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.codehaus.gmavenplus:gmavenplus-plugin:1.1-SNAPSHOT
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/Users/lc/.m2/repository/org/codehaus/gmavenplus/gmavenplus-plugin/1.1-SNAPSHOT/gmavenplus-plugin-1.1-SNAPSHOT.jar
[ERROR] urls[1] = file:/Users/lc/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]

Wow. OK, something must be different about your setup than mine, because this worked for me. What version of Maven are you using?

Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00)
Java version: 1.7.0_51, vendor: Oracle Corporation

I'll try to do more tests later this week

Strange, that's the same setup I'm running. I've attached the sample project I created that worked for me. See if that seems to work.

Reopening until fix has been verified

Hi Keegan,

ok, it works, sorry for the delay and extra work. It's a config issue on my side.

Installing the module by hand using "mvn install:install-file" did not produce a complete pom file, hence the class not found.

It's all good. This issue can be closed.

Regards,
Laurent

Ah, I suspected it was probably something simple like that. Thanks for verifying.

Arghh, I need to read my own integration tests. The workaround for this is to use a URL instead of a file path, for example

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

Reopening because console doesn't seem to allow scripts be run more than once for some Groovy versions. I'm doing more research on what those versions are.

Seems to affect all versions older than 1.7.1. I'm not sure why yet, or if there's any way to work around the issue.

Actually, having downloaded the zip of 1.7.0, it looks like that problem exists in the official binaries as well, it's not specific to GMavenPlus. I guess I'll just ship as-is.

I'm still trying to figure out a way to do this without completely forking Groovy's stub generation.

I've finally concluded there is no way without forking Groovy's stub generation, which I refuse to do. If people want this feature, they should push for it to be patched upstream.

Migrated back to GitHub.

I've not done this already because I'm not sure how to wire in the component configurator with arguments to control dependency resolution and which classpath to include.

I don't think this pipe dream is actually possible.

Migrated back to GitHub.

I don't think I'm going to do this. Java 1.4 is miserable to program in and nobody should be using it anymore anyway. If someone actually asks for it, maybe I'll reconsider.

Migrated back to GitHub.

This is really puzzling. No exceptions are thrown, Groovy just silently doesn't create any stubs. I'm backtracking through release history to figure out what changed that might explain this.

I think this was fixed with GROOVY-4711, specifically commit 5d726fd9d2090b6a1c2669da7c5972f8229c1ae4. The problem is what to do with versions of Groovy before that. I'm trying to find a way to incorporate this fix without forking Groovy code the way GMaven did.

Migrated back to GitHub.

I've committed an initial fix for this. I'm just slogging through testing it in all the various Groovy releases.