Provide new addProjectClasspath parm to exclude project target & deps from goal classpath for fine-grained control

[scottkurz]

Signed-off-by: Scott Kurz skurz@us.ibm.com

I think it could be desirable to give more fine-grained control of the classpath and exclude project dependencies and the default target location, and use only the plugin config, e.g.

      <classes>${project.build.directory}/my-unpack</classes>

Added as

   /**
     * By default (with value set to <true>) the project build directory as well as the project dependencies are added to the sigtest classpath.
     * If set to <false> then only the path configured in <code>classes</code> will be added to the sigtest classpath for this goal.
     */
    @Parameter(defaultValue = "true", property = "sigtest.addProjectClassPath")
    private boolean addProjectClasspath;

So you can set as:

   <configuration>
       <addProjectClasspath>false</addProjectClasspath>
   </configuration

or -Dsigtest.addProjectClassPath=false

The default of true matches the existing behavior.

[scottkurz]

I didn't want to get stuck on naming the new parameter. Not sure I really like my choice: sigtest.addProjectClassPath but can at least get the code up here for comment.

[scottmarlow]

Looks good to me! I'm pretty sure that I know the answer to my question I asked but just wanted to confirm.

[jtulach]

Would the same use-case be addressed by creating a new pom.xml without any dependencies and using the existing Sigtest plugin in there?

While the boolean flag may be sufficient for your use-case, I find it quite unique. Is there any other Maven plugin that tries to disable classpath this way? Can you name few examples? I've only reminded myself of maven-exec-plugin and its classpathScope parameter...

[scottkurz]

While the boolean flag may be sufficient for your use-case, I find it quite unique. Is there any other Maven plugin that tries to disable classpath this way? Can you name few examples? I've only reminded myself of maven-exec-plugin and its classpathScope parameter...

I appreciate your point and can't think of other examples.

To restate the use case: say I'm starting with a pre-Maven (e.g. Ant) type of execution and I want to bridge or migrate from this Ant env to the Maven plugin. The fact that I can't just point to the same classpath I was using before but now have to build an equivalent through transitive Maven dependencies (which aren't trivially simple, being different per scope) is an inconvenience. This requires just a bit deeper Maven experience.

Would the same use-case be addressed by creating a new pom.xml without any dependencies and using the existing Sigtest plugin in there?

But yes, adding a new module would certainly work.

[jtulach]

But yes, adding a new module would certainly work.

Good to know a solution exists.

I believe the core concept of Maven is its dependency management and the way it constructs classpath. I'd like stick with it rather than inventing alternative classpath management. As such please use the empty pom.xml with no dependencies and let's wait with this PR until it is really needed.

Should such need really appear, I am ready to accept maven-exec-plugin like classpathScope parameter...

[scottkurz]

I believe the core concept of Maven is its dependency management and the way it constructs classpath. I'd like stick with it rather than inventing alternative classpath management. As such please use the empty pom.xml with no dependencies and let's wait with this PR until it is really needed.

Well, it's your project and that sounds fair enough. Thanks for giving it some thought.