An option to execute only with jars configured for the plugin in the POM

[ppalaga]

useSharedClassLoader=true means dependencies configured for the plugin + current project's (test or runtime? - undocumented) class path.

useSharedClassLoader=false means current project's test class path only.

There is no way to execute the mojo with dependencies configured for the plugin only.

Background: I am executing an inline script for each module of a mid-size multimodule tree. For some modules (the ones depending on rest-assured which pulls another version of groovy), I am getting classpath version conflicts, that I would not get if I had the option to run only with dependencies I explicitly configure for the plugin in the POM.

[keeganwitt]

The behavior of the shared classloader is that it includes whatever the dependency resolution of the goal you're running. So could be compile, compileTest, or runtime, depending on the mojo. I'll adjust the parameter description to make that clearer.

I'm a little confused about the issue you're describing. If there are conflicting versions Groovy being picked up by the plugin, they'd be conflicting within your project as well, right?

[ppalaga]

Sorry, I should have explained better what happens and what I'd eventually wish as a solution.

I run the execute mojo and I found no way to configure it to use only the dependencies declared for the plugin. E.g. given that I have

<plugin>
        <groupId>org.codehaus.gmavenplus</groupId>
        <artifactId>gmavenplus-plugin</artifactId>
        <version>1.7.1</version>
        <executions>
          <execution>
            <goals>
              <goal>execute</goal>
            </goals>
          </execution>
        </executions>
      <configuration>
        ...
      </configuration>
      <dependencies>
        <dependency>
          <groupId>org.codehaus.groovy</groupId>
          <artifactId>groovy-all</artifactId>
          <version>2.5.7</version>
          <type>pom</type>
          <scope>runtime</scope>
        </dependency>
      </dependencies>
  </plugin>

and one of the Maven modules depends transitively on an older Groovy version, the mojo fails in that module due to a version conflict.

I am looking for a way to configure the mojo so that does not mix in the given Maven module's dependencies. It should include only the dependencies under the <plugin> element.

[keeganwitt]

I could see if you had to include Groovy in the plugin's dependencies because not all modules have the dependency, and you also care about which Groovy version wins, it could be a problem. In my testing, it didn't fail just because there was a conflict (though perhaps our config isn't quite the same).

To give you this option, I'd need to conditionally apply the mojo configurator, which I'm not sure how to do yet (assuming Maven even lets me do that). If Maven doesn't have that option (which I kinda suspect is the case), the only other way I can think of is to have totally different goals, like compile-isolated and compileTests-isolated or something like that, which would kinda suck.

[keeganwitt]

I think I found a path for this. The PlexusConfiguration passes in the configuration for the plugin, which I should be able to read and make the configurator a no-op if a new option to use only the plugin classpath is passed.

I'm also trying to decide between a parameter with an enum of 3 possible values like PROJECT_ONLY, PROJECT_AND_PLUGIN, and PLUGIN_ONLY instead of two mutually exclusive booleans (which might be kinda confusing).

[ppalaga]

I tested with your 140 branch and <includeClasspath>PLUGIN_ONLY</includeClasspath> and the issue does not occur anymore. Thanks!

[keeganwitt]

Cool! Thanks for checking it out! I'm still working on some testing, but I think I've got the right idea.

[keeganwitt]

I've deployed a snapshot with this change: https://oss.sonatype.org/content/groups/staging/org/codehaus/gmavenplus/gmavenplus-plugin/1.8.0-SNAPSHOT/.

[keeganwitt]

I apologize for the delay in shipping this. I'd planned to ship this with incremental compilation, but that proved to be more complex than I'd originally hoped, then I didn't have the free time to do some QA and get it released. I'm looking to do that this weekend.

[ppalaga]

No problem, we switched to the gmaven plugin for now, where the problem does not occur.

[keeganwitt]

I just completed the release. Let me know if you encounter any problems.