Q: custom maven plugin - how to determine current project module?

[Bear Giles <bg...@coyotesong.com>]

This is probably mindnumbingly obvious and my google and SO skills are
horrible but here goes....

I'm working on a complex project with multiple tiers of modules. In some
cases I want to build one module, plus its dependencies (-am), and upload
it to a server via a REST call. I didn't have a problem writing the maven
plugin with a hard-coded path. Or I'll want to build several related
modules and upload all of them.

I want to be able to upload a path relative to the module I'm building. I
haven't written a plug-in to dump all system properties and environment
variables yet so it's probably something as simple as, the pom.xml
properties, e.g., $project.name, also being available as system properties.
But it's not documented and I'm paranoid about things that aren't
documented since they often change without warning.

So:

1. is that the case?

2. is there a reason the "write a custom maven plugin" pages don't mention
it early and often, at least on the page that discusses how to get
information from your custom plugin's configuration stanza?

... a related question. If one plugin sets a system property, e.g., that
'buildId' I mentioned earlier, will it be visible to all of the other maven
plugins during that run? Even if the build is multi-threaded? In this case
there would be one custom plugin that generates the build id and uploads
the artifact but it would set a value that could then be used by other
plugins during the build. Basically a -Dname=value, but doing it via a
plugin instead of the command line.

Thanks,

Bear

Re: custom maven plugin - how to determine current project module?

[Martin Gainty <mg...@hotmail.com>]

MG>not obvious see below
________________________________
From: Bear Giles <bg...@coyotesong.com>
Sent: Thursday, October 4, 2018 5:13 PM
To: Maven Users List
Subject: Q: custom maven plugin - how to determine current project module?

This is probably mindnumbingly obvious and my google and SO skills are
horrible but here goes....

I'm working on a complex project with multiple tiers of modules. In some
cases I want to build one module, plus its dependencies (-am), and upload
it to a server via a REST call. I didn't have a problem writing the maven
plugin with a hard-coded path. Or I'll want to build several related
modules and upload all of them.

I want to be able to upload a path relative to the module I'm building. I
haven't written a plug-in to dump all system properties and environment
variables yet so it's probably something as simple as, the pom.xml
properties, e.g., $project.name, also being available as system properties.
But it's not documented and I'm paranoid about things that aren't
documented since they often change without warning.

So:

1. is that the case?

2. is there a reason the "write a custom maven plugin" pages don't mention
it early and often, at least on the page that discusses how to get
information from your custom plugin's configuration stanza?

... a related question. If one plugin sets a system property, e.g., that
'buildId' I mentioned earlier, will it be visible to all of the other maven
plugins during that run? Even if the build is multi-threaded?

MG>starting with maven 3 you can request n-number thread allocation per cpu-core directive in maven
https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3
Parallel builds in Maven 3 - Apache Maven - Apache ...<https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3>
Maven 3.x has the capability to perform parallel builds. The command is as follows: mvn -T 4 clean install # Builds with 4 threads mvn -T 1C clean install # 1 thread per cpu core mvn -T 1.5C clean install # 1.5 thread per cpu core. This build-mode analyzes your project's dependency graph and schedules modules that can be built in parallel according to the dependency graph of your project.
cwiki.apache.org


 In this case
there would be one custom plugin that generates the build id and uploads
the artifact but it would set a value that could then be used by other
plugins during the build. Basically a -Dname=value, but doing it via a
plugin instead of the command line.
MG>from what little you have shared i believe maven-resources-plugin (resources:resources) will handle property
MG>manipulation
https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html
Apache Maven Resources Plugin – resources:resources<https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html>
Copy resources for the main source code to the main output directory. Always uses the project.build.resources element to specify the resources to copy.
maven.apache.org

MG>keep in mind these implementations are classloader-dependent
MG>not such a big deal with launch but later plugin invocations may use their own classloaders
MG>so your forked classloader *eg surefire-plugin* may not see maven classloader properties
MG>unless you configure SystemPropertyVariables  for that plugin
http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html
Maven Surefire Plugin – Using System Properties<http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html>
The string ${project.build.outputDirectory} will be passed on literally because the type of that expression is a File, not a String.. To inherit the systemProperties collection from the parent configuration, you will need to specify combine.children="append" on the systemProperties node in the child pom:
maven.apache.org



Thanks,

Bear