Remove release plugin arguments from pom.xml and update workflows

[Copilot]

Description

The maven-release-plugin fails when -pl arguments are passed via <arguments> configuration in pom.xml:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare
Unrecognized option: -pl

Resolves https://github.com/BerryCloud/xapi-java/actions/runs/19414252617

Changes

pom.xml

• Remove <arguments> configuration from maven-release-plugin

Workflows

• Use -pl and -am flags directly in all Maven commands with consistent syntax across both workflows
• In maven-publish.yml: Place -pl and -am flags directly before the release:prepare release:perform goals
• In release.yml: Place -pl and -am flags directly before both release:prepare and release:perform goals

Example from maven-publish.yml:

mvn -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am -batch-mode release:prepare release:perform --file pom.xml

Example from release.yml (release:prepare):

./mvnw -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am release:prepare \
  -DreleaseVersion="${VERSION}" \
  -Dtag="${TAG_NAME}" \
  -DpushChanges=false

Example from release.yml (release:perform):

./mvnw -B -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am release:perform \
  -DlocalCheckout=true \
  -DeployAtEnd=true

Both workflow files now use the same consistent syntax with -pl and -am flags placed directly in the Maven command (not wrapped in -Darguments), ensuring only production modules (xapi-model, xapi-client, xapi-model-spring-boot-starter) are released while excluding all sample modules.

Checklist:

• Public methods are documented

• Public methods are tested

• New and existing tests pass when run locally

• There are no new warnings or errors

• Fixes [Chore]: Remove release plugin arguments from pom.xml and update workflows #354

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Chore]: Remove release plugin arguments from pom.xml and update workflows</issue_title>
<issue_description>### What

Remove the setting from the maven-release-plugin in pom.xml, as it is causing the release process to fail. The arguments (-pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am) should be moved to the relevant Maven commands in GitHub workflows so only workflow steps needing them actually use them.

Why

Specifying production module arguments in the plugin configuration causes releases to fail in our CI/CD flow. Placing these arguments in the workflow command will allow more flexible and correct operation, resolving the release process failures.

Notes

Search and remove the tag from the maven-release-plugin configuration in pom.xml. Update Github workflow YAML files that call mvn release so they include the arguments directly (e.g. -pl xapi-model,xapi-client,xapi-model-spring-boot-starter -am) in the Maven command. Test the release to confirm the issue is resolved.</issue_description>

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

@thomasturrell Specifically this build failed. https://github.com/BerryCloud/xapi-java/actions/runs/19414252617

• Fixes [Chore]: Remove release plugin arguments from pom.xml and update workflows #354

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[thomasturrell]

@copilot did you see my new comment

[Copilot]

@copilot did you see my new comment

Yes, I've addressed your comment. The release:perform step now uses the same -pl syntax as maven-publish.yml. Commit: 5799f93

[thomasturrell]

@copilot do i need the --file pom.xml parameter and value

[Copilot]

@copilot do i need the --file pom.xml parameter and value

No, --file pom.xml is not needed when running from the repository root since Maven defaults to using pom.xml in the current directory.

However, it's currently used consistently in other workflows (maven-publish-snapshot.yml, maven_pull_request.yml, maven_push.yml).

For consistency with release.yml (which doesn't use it), you could remove it. Or keep it for explicitness to match the other workflows - both approaches work fine.

[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