Fix maven-release-plugin to inherit module filters in forked Maven invocations

[Copilot]

Description

The maven-release-plugin forks Maven for internal verification but doesn't inherit command-line reactor filters (-pl/-am). When release workflows filtered to production modules, the forked verify ran against all modules including samples, which still referenced SNAPSHOT parents and failed with "Non-resolvable parent POM".

Resolves #143

Changes

• Added -Darguments="-pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am" to release:prepare and release:perform invocations in .github/workflows/release.yml
• Applied same fix to deprecated .github/workflows/maven-publish.yml for consistency

The -Darguments parameter passes module filters to forked Maven invocations, ensuring samples are excluded from internal verification steps.

Checklist:

• Public methods are documented
• Public methods are tested
• New and existing tests pass when run locally
• There are no new warnings or errors

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Chore]: Fix maven-release-plugin invocation in release workflow (forked verify does not inherit -pl/-am)</issue_title>
<issue_description>### 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.</issue_description>

Comments on the Issue (you are @copilot in this section)

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

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud