Update release.yml

[mlakov]

Fix Maven Arguments in Release Workflow

Bug Fix

🐛 Updated the maven-extra-args parameter in the release workflow to use -f cds-feature-ord/pom.xml instead of -pl cds-feature-ord -am, ensuring the correct POM file is targeted during the Maven deploy step.

Changes

• .github/workflows/release.yml: Replaced the -pl cds-feature-ord -am Maven argument with -f cds-feature-ord/pom.xml to directly reference the module's POM file for the deploy action.

• 🔄 Regenerate and Update Summary

PR Bot Information

Version: 1.29.9

• Output Template: Default Template
• Summary Prompt: Default Prompt
• Event Trigger: pull_request.opened
• File Content Strategy: Full file content
• Correlation ID: f21860e0-8cb1-11f1-94ff-4b40e54a6d9a
• LLM: anthropic--claude-4.6-sonnet

[hyperspace-pr-bot]

Now I have enough context. Let me analyze the change carefully.

Key facts:

1. The project has a root pom.xml (artifact cds-feature-ord-root) with a <modules> section that includes cds-feature-ord as a submodule.
2. The child cds-feature-ord/pom.xml has <parent> pointing to the root, and uses ${revision} inherited from the root.
3. The old arg was -pl cds-feature-ord -am (build only that module and its dependencies, run from root).
4. The new arg is -f cds-feature-ord/pom.xml (point directly at the child POM, bypassing the root POM entirely).

The problem with -f cds-feature-ord/pom.xml:

• The root pom.xml is where <revision> is defined (in <properties>), and where distributionManagement, pluginManagement, dependencyManagement, and all build plugin versions are declared.
• The child POM inherits all of these from the parent via the <parent> tag. However, when running with -f cds-feature-ord/pom.xml from a directory where the root POM is the parent, Maven will still look up the parent POM from the local repository or relative path — but flatten-maven-plugin is needed to resolve ${revision} at deploy time.
• More critically: the central-publishing-maven-plugin is configured in the child POM's deploy-release profile. But the revision property is defined only in the root POM. When running -f cds-feature-ord/pom.xml directly, Maven resolves the parent via relativePath (which defaults to ../pom.xml), so the property resolution itself should still work.
• However, the verify-version step (line 50) runs mvn help:evaluate -Dexpression=revision from the root directory without any -f flag — this reads from the root POM, which is fine.
• The real concern: with -f cds-feature-ord/pom.xml, Maven runs only against the child module. The deploy-release profile (with GPG signing and the central-publishing-maven-plugin) is defined in the child POM, so that's fine. But the distributionManagement is defined in the root POM, which is inherited — this should still be accessible.

The most significant correctness issue is: -f cds-feature-ord/pom.xml changes the working directory context. Maven with -f sets the project base dir to the directory containing the specified POM (cds-feature-ord/), not the repo root. Any relative paths or plugin configs relying on the root being the base dir could break. Also, flatten-maven-plugin with ossrh mode rewrites ${revision} — when invoked via -f, it must resolve the parent POM correctly via relative path ../pom.xml, which it should since it's checked out.

Actually the most concrete issue: the old -pl cds-feature-ord -am also builds all dependencies (-am = also-make), meaning it builds the root and any other modules cds-feature-ord depends on. With -f cds-feature-ord/pom.xml, Maven doesn't know about the multi-module structure and builds only the single module. For a single-module project like this, that's fine behavior-wise.

However, the revision property is declared in the root POM. When Maven is invoked with -f cds-feature-ord/pom.xml, it will find the parent via <relativePath> (default ../pom.xml), so ${revision} should still resolve. The flatten-maven-plugin also processes it correctly at process-resources phase.

The real issue is that -f cds-feature-ord/pom.xml skips running the root POM's build lifecycle, including the flatten-maven-plugin execution configured only in the child. Since the root POM doesn't have flatten configured, that's fine.

But wait — looking at the deploy-release action: the action is at cap-java/.github/actions/deploy-release@main and is a shared action. The maven-extra-args get prepended/appended to the mvn command. If the action runs mvn deploy from the repo root, then -f cds-feature-ord/pom.xml is a valid way to target only the child module without going through the multi-module reactor. However, revision used as a -Drevision=... by the action (based on the revision input param) should override the property anyway.

The main behavioral difference and potential issue: the old approach -pl cds-feature-ord -am runs from the root of the multi-module project (reading pom.xml first), while -f cds-feature-ord/pom.xml targets the child POM directly. The distributionManagement section is in the root POM — the child inherits it via parent resolution, which works as long as the parent POM is locatable. Since the parent POM is in the same repo and resolved via relativePath, this should work.

One subtle but real issue: pluginManagement entries (like maven-gpg-plugin version, central-publishing-maven-plugin version, etc.) are all in the root POM's pluginManagement. The child POM inherits these via the parent mechanism (resolved via relative path), so this is fine.

I don't see a hard correctness bug here — the change should functionally work for a single-module Maven project like this. The behavior is equivalent: both target only cds-feature-ord for the deploy step. The -f approach is actually more direct and avoids the reactor overhead. Let me check if there's a concern about revision not being set when running directly against the child POM without the -Drevision override.

Looking at the workflow: the revision input is passed to deploy-release action (line 123). The action likely passes it as -Drevision=.... So ${revision} will be properly set.

This change looks essentially correct. The only thing worth noting: with -pl cds-feature-ord -am, Maven would also build any inter-module dependencies of cds-feature-ord within the multi-module project (there are none here — it's the only module), so -am was effectively a no-op. The -f approach is cleaner for a single-module release.

No substantive defect found. The change is a straightforward, equivalent simplification.

This is a small, focused change that replaces -pl cds-feature-ord -am with -f cds-feature-ord/pom.xml in the deploy step. Both approaches correctly target only the cds-feature-ord child module for the Maven deploy; since this is the only module in the project, the -am (also-make) flag in the old form was a no-op. The new -f form is a valid and direct equivalent. No substantive issues were identified.

PR Bot Information

Version: 1.29.9

• Event Trigger: pull_request.opened
• Experiment Variant: control
• File Content Strategy: Full file content
• Correlation ID: f21860e0-8cb1-11f1-94ff-4b40e54a6d9a
• LLM: anthropic--claude-4.6-sonnet