Repository navigation
ci: build the Java release pom in CI, and fix its jar execution - #128
Merged
Merged
Conversation
The Java build copies bindings/java/release/pom.xml over the generated pom, but CI built the generated pom. Dependabot updates to the release pom were merged without a build, and a maven-jar-plugin 3.x update would break the deploy build. Make bindings/java/test.sh build the release pom with the package version, and run the package phase that deploy.sh uses. Move the copy into write_release_pom in scripts/common.sh, so the build and the tests use the same pom. Remove the duplicate jar goal from the jar execution. Maven already builds the main jar, and maven-jar-plugin 3.x rejects the second one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The changes consistently exercise the deploy configuration and resolve the Maven 3.x JAR conflict.
0 open findings
What changed in this PR
Updates Java CI to validate the maintained release POM and its deployable artifacts.
Changes:
- Shares release POM version generation between build and test scripts.
- Runs Java tests and package creation against the release POM.
- Prevents duplicate main JAR creation.
| File | Description |
|---|---|
scripts/common.sh |
Adds shared release POM generation. |
bindings/java/test.sh |
Tests and packages using the release POM. |
bindings/java/release/pom.xml |
Removes duplicate main JAR execution. |
bindings/java/build.sh |
Uses the shared POM helper. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unblocks #127.
Problem
bindings/java/build.shcopiesbindings/java/release/pom.xmlover the generated pom. Dependabot updates the release pom. But CI ranmvn testagainst the generatedbindings/java/src/pom.xml, so:Change
bindings/java/test.shwrites the release pom with the package version tosrc/.release-pom.xml. It runsmvn testand thenmvn -DskipTests packageagainst it, and deletes the file on exit. The package phase builds the main, javadoc, sources and tests jars thatdeploy.shuploads.write_release_pominscripts/common.shholds the copy, sobuild.shandtest.shproduce the same pom.release/pom.xml: the custom jar execution now runs onlytest-jar. Maven's default execution already builds the main jar, and maven-jar-plugin 3.x refuses to build it twice.Verification
On
cimg/openjdkwith the newtest.sh:maven-jar-plugin:3.5.1:jar(the new test catches it)The generated
src/pom.xmldoes not change here. The next "Update API bindings" run copies the release pom into it, with #126's plugin versions, and bumps the version.After this merges, comment
@dependabot rebaseon #127 so that its CI runs the new test.🤖 Generated with Claude Code