[Chore]: Fix maven-release-plugin invocation in release workflow (forked verify does not inherit -pl/-am)

[thomasturrell]

What

The release workflow failed (job: https://github.com/BerryCloud/xapi-java/actions/runs/19433375623/job/55597733638) because release:prepare was invoked with module filters (-pl ... -am) so only the selected modules were transformed, but the maven-release-plugin internally runs a forked mvn "clean verify" which did not inherit the outer -pl/-am. The internal verify ran against the full reactor (including samples), but the samples were not updated and still reference the SNAPSHOT parent, causing a Non-resolvable parent POM error.

Reproduction

Workflow runs the release command used in the job: ./mvnw -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am release:prepare
-DreleaseVersion="${VERSION}"
-Dtag="${TAG_NAME}"
-DpushChanges=false
release:prepare does a forked mvn clean verify that does not inherit -pl/-am.
The samples module (samples/pom.xml) is verified even though it wasn’t transformed, which fails because the parent POM version wasn’t changed.

Root cause

The maven-release-plugin forks its own Maven execution for certain checks and does not automatically inherit command-line reactor filters (-pl/-am) from the outer invocation. The plugin must be told explicitly which arguments to pass to its internal Maven invocation using -Darguments or plugin configuration.

Suggested fixes (pick one)

Preferred quick fix — pass reactor filters to the plugin via -Darguments in the release command
Change the release command in the workflow to include -Darguments with the same -pl/-am flags so the plugin’s forked invocation uses the same reactor filtering: ./mvnw -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am
release:prepare
-DreleaseVersion="${VERSION}"
-Dtag="${TAG_NAME}"
-DpushChanges=false
-Darguments="-pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am"

If you also run release:perform, apply the same -Darguments to that invocation.

Or add a pre-step that installs/publishes the parent POM before release:prepare so samples can resolve the parent during verify.

Suggested workflow change (example)

Edit .github/workflows/release.yml (current ref: https://github.com/BerryCloud/xapi-java/blob/00558e6b54faa692844d7ef5a0220d1775886809/.github/workflows/release.yml) to update the release command to include -Darguments. Example step:
name: Run release prepare run: | ./mvnw -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am
release:prepare
-DreleaseVersion="${VERSION}"
-Dtag="${TAG_NAME}"
-DpushChanges=false
-Darguments="-pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am"

Files to check

samples/pom.xml (failing project): https://github.com/BerryCloud/xapi-java/blob/00558e6b54faa692844d7ef5a0220d1775886809/samples/pom.xml
workflow: https://github.com/BerryCloud/xapi-java/blob/00558e6b54faa692844d7ef5a0220d1775886809/.github/workflows/release.yml

Acceptance criteria

release:prepare no longer runs verification on samples that weren’t transformed.
The CI run completes successfully (no Non-resolvable parent POM errors).
If using the -Darguments approach, logs show the plugin’s forked invocation includes the -pl/-am flags.
If using the POM configuration approach, plugin configuration is added and documented.

Notes

Passing -Darguments is the least invasive change and should fix the immediate CI failures.

Why

This change is necessary because the current workflow causes the CI 'release:prepare' step to fail due to Non-resolvable parent POM errors, by incorrectly verifying modules that weren’t updated. Updating the release command resolves the failure and ensures correct deployment.

Notes

Work references:

• Workflow job: https://github.com/BerryCloud/xapi-java/actions/runs/19433375623/job/55597733638
• Workflow file: https://github.com/BerryCloud/xapi-java/blob/00558e6b54faa692844d7ef5a0220d1775886809/.github/workflows/release.yml
• Failing POM: https://github.com/BerryCloud/xapi-java/blob/00558e6b54faa692844d7ef5a0220d1775886809/samples/pom.xml

Notes:

• The preferred quick fix is to add -Darguments to the release command. Alternative is to install/publish the parent POM before prepare.
• Ensure workflow changes result in successful CI run and proper module verification.