'runOnlyOnce' coupled with Maven's --projects param makes plugin not run at all

[fmarot]

Describe the bug

In the case of a multi-module Maven project, when we use the 'runOnlyOnce=true' parameter coupled with 'injectAllReactorProjects=true', we expect the plugin to run once to calculate all git variables and we expect those variables to be available in children projects.

But this is not the case when we run Maven on a specific sub-project:
mvn install --projects mySubProject

neither when we use this command to resume from a specific sub-project:
mvn install -rf mySubProject

Steps to Reproduce

• Here is the config in the parent pom:

			<plugin>
				<groupId>pl.project13.maven</groupId>
				<artifactId>git-commit-id-plugin</artifactId>
				<version>2.2.5</version>
				<executions>
					<execution>
						<id>get-the-git-infos</id>
						<goals>
							<goal>revision</goal>
						</goals>
						<phase>initialize</phase>
						<configuration>
							<generateGitPropertiesFile>false</generateGitPropertiesFile>
							<runOnlyOnce>true</runOnlyOnce>
							<injectAllReactorProjects>true</injectAllReactorProjects>
							<verbose>true</verbose>
							<skipPoms>false</skipPoms>
						</configuration>
					</execution>
				</executions>
			</plugin>

Expected behavior

mvn install --projects mySubProject

we expect to see the verbose logs of all the variables calculated.
But in fact we get this:

[INFO] --- git-commit-id-plugin:2.2.5:revision (get-the-git-infos) @ mySubProject ---
[INFO] runOnlyOnce is enabled and this project is not the top level project, skipping execution!

Additional context

version tested is the last released: 2.2.5

My analysis:

The code in GitCommitMojo looks like

if (runOnlyOnce) {
        if (!session.getExecutionRootDirectory().equals(session.getCurrentProject().getBasedir().getAbsolutePath())) {
          log.info("runOnlyOnce is enabled and this project is not the top level project, skipping execution!");
          return;
        }
      }

=> so the code expects to run at least once from Maven's ExecutionRootDirectory. But there it does not happen.

My suggestion is to set a variable (user variable ?) the first time the plugin is ran and when this variable is already set, we bypass the execution in case 'runOnlyOnce=true'
I will provide a Pull Request soon.

[TheSnoozer]

Hi,
thanks for posting this issue here!
I'll need to investigate if there are better alternatives to actually runOnlyOnce in such cases.

Based on the doc the plugin is somewhat behaving as desired:

In a multi-module build, only run once. This means that the plugins effects will only execute once, for the parent project.

I'm not sure yet if setting some variables (e.g. user variables) would be the most reliable way. Especially when you run maven in parallel (e.g. mvn -T 4 clean) this might be prone to race conditions.

[fmarot]

@TheSnoozer you're right regarding the parallel execution. However I feel like the risk is lower than the benefits but I totally understand your concerns. I'll be interested if there is a best way to correct this problem.

[TheSnoozer]

I need to look into that more carefully.

Seems our runOnlyOnce configuration got inspired by https://blog.sonatype.com/2009/05/how-to-make-a-plugin-run-once-during-a-build/

The article states that the mavenAssemblyPlugin has adopted that...however they 'cheated' and called the option runOnlyAtExecutionRoot (see http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#runOnlyAtExecutionRoot).

[fmarot]

Your link to the Sonatype blog reminded me that I already discussed this exact same problem on the Maven mailing-list ( http://maven.40175.n5.nabble.com/Make-custom-plugin-executed-only-once-in-multimodule-inherited-false-aggregator-td5921630.html ) and... it seems there is no real solution :/

[fmarot]

I've just realized that during the build, the Mojo is instantiated multiple times (once per module) but it is always the same class so maybe we could have a thread-safe static instance of something preventing concurrent access. It would be better that user variables.
I fear there may be edge cases where different classes are used through different classloaders (maybe if you define multiple versions of the same plugin in different modules part of the same reactor) but is this really cases we have to consider ?

[TheSnoozer]

Your link to the Sonatype blog reminded me that I already discussed this exact same problem on the Maven mailing-list ( http://maven.40175.n5.nabble.com/Make-custom-plugin-executed-only-once-in-multimodule-inherited-false-aggregator-td5921630.html ) and... it seems there is no real solution :/

Unfortunately I don't see any obvious solution either and a popular search engine didn't yield any obvious results.

The issue is simply that maven has it's many pitfalls.
You need to consider parallel execution, multiple configurations across different child poms, multiple executions within a single child pom, ...maven might even behave differently when called with mvn clean package VS mvn com.test.plugins:testPlugin:deployMojo (example https://issues.apache.org/jira/browse/MNG-6260). On top of that all you also need to consider to support essentially all 3.X maven versions since none of them are marked as 'end of life'. So even if something might become available in 3.6.X we might not be able to integrate it into the plugin, cause anyone should really be able to choose a maven version that is not 'end of life' (also consider legacy CI systems that never get updated).

I've just realized that during the build, the Mojo is instantiated multiple times (once per module) but it is always the same class so maybe we could have a thread-safe static instance of something preventing concurrent access. It would be better that user variables.
I fear there may be edge cases where different classes are used through different classloaders (maybe if you define multiple versions of the same plugin in different modules part of the same reactor) but is this really cases we have to consider ?
Thanks for the investigation. Mhh...in my past experience with maven it always bit me hard when I tried to something that is 'not the maven way'. At least from my perspective in the maven world you rather don't want to invent "hacks". When already think about edge cases...in all fairness I can't speak for every user of the plugin and I can't even tell how many users are out there. There is simply no possible way to tell how the plugin is used, what edge cases to consider and what could safely be ignored.

I truly can understand your thinking behind raising this issue and would be happy to integrate it in some (reliable) way into the plugin. However at this stage I'd rather tend to say that the actual runOnlyOnce feature is not really well supported within maven. I'd prefer not to invent a hack to have such a support in the plugin. If there is an official way, sure let's do that. However unfortunately there doesn't seem to be an obvious one available.

Feel free to add further comments if you actually find a working solution, but messing around with different classloaders and all cases I listed above seems a bit unpredictable for me (feel free to convince me wrong).

For now I would say, yes the option is badly worded, but does exactly what is described in the documentation.

[fmarot]

Hello @TheSnoozer , and thanks for your long reply.
I have a few remark though:

1- I've exeprimented on a large project (100 Maven modules) with running 'mvn initialize' with runOnlyOnce=true/false.
runOnlyOnce=true --> 40seconds
runOnlyOnce=false --> 9 minutes (!)
So my conclusion is that runOnlyOnce=true is a feature I cannot do without.

2- I'd rather have the plugin also run when a developper runs 'mvn install --projects submodule'. If it does not run, with this standard Maven command (which is recommanded over running the command directly inside the submodule) the developpers will randomly have git properties not initialized which may lead to jars containing incomplete infos.
This is really worrying for me: I'd rather be the plugin be consistent in some classis use-case rather it be consistent in some very strange use-case (see 4.2 and the potential problems when there would be multiple versions of the plugin in the same reactor)

3- So my conclusion is we must do something for this classic use-case.

4- Problem is how to do it ?
4.1- User property base implementation

• if we have the user-properties based implementation we risk in rare case the plugin to execute multiple times.
  • in most situations where there is a single git repo, this is not a problem because computed properties will always be the same.
  • in situations where there are multiple git repos, it may lead to overwritten properties of the 1st git repo with the ones from the second git repo.
    This is coherent with the current documentation stating that "This probably won't 'do the right thing' if your project has more than one git repository".

4.2- synchronized static variable in Mojo implementation

• this should do the job when there is a single versiobn of the plugin defined in the reactor.
• problem arise when multiple versions of the plugin are defined in the reactor: they all will be executed once... But I tend to think it is not a very standard configuration. Who would want to do that ?! It could 'just' be documented as "we do not support using multiple versions of the plugin in the same reactor".

5- the plugin is going toward it's 3.0 release so it seems to me like the right time a change a bit of a feature that may break something (even though I do not see how it could break stuffs but I acknowlege there are many edge cases). But Itotally understand that you may not want to take the risk to break stuffs.

Regards

update1: for info, here is how the buildnumber-maven-plugin does with its 'getRevisionOnlyOnce' param: https://github.com/mojohaus/buildnumber-maven-plugin/blob/7faf13a6a67c5e7762f7cf3609178fedfd47c8d3/src/main/java/org/codehaus/mojo/build/CreateMojo.java#L273