Keep runtime deps in published POM; auto-publish to Maven Central#28
Merged
Conversation
Two fixes to how the artifact is published: 1. createDependencyReducedPom=false: with the uber jar attached as the 'shaded' classifier, maven-shade-plugin's default dependency-reduced POM stripped every dependency that was shaded into the uber jar (Jetty, Apache HTTP, commons-cli, Jackson, ...). That left the published thin main jar declaring only test-scoped deps, so consumers got a jar with no resolvable runtime dependencies. Keep the full dependency list in the published POM. 2. autoPublish=true + waitUntil=published: the central-publishing-maven-plugin defaulted to a manual release, so 'mvn deploy' only uploaded a *pending* deployment that then had to be released by hand in the Central Portal (which is why 4.8 built green but never appeared on Maven Central). Now a deploy from either release.yml (on tag) or the manual Publish workflow actually publishes.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Maven build now automatically publishes Central releases, waits for the published state, and retains the original dependency POM when creating the shaded artifact. ChangesMaven release configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Comment |
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.
Follow-up to #27. Two fixes to how the Maven artifact is published — both needed before 4.x can be consumed from Maven Central (and the reason 4.8 built green but never appeared there).
1. Keep runtime dependencies in the published POM (critical)
#27 attaches the uber jar under the
shadedclassifier and publishes a thin main jar. Butmaven-shade-plugindefaults tocreateDependencyReducedPom=true, which removes from the published POM every dependency that was shaded into the uber jar — i.e. Jetty, Apache HTTP, commons-cli, Jackson, logback, jsch, prometheus.Result: the thin
TestingBotTunnel.jarpublished to Central declared only test-scoped dependencies, so any consumer got a jar whose runtime classes were unresolvable (NoClassDefFoundError: org/apache/commons/cli/..., missing Jetty, etc.).Fix:
createDependencyReducedPom=false. Verified locally — the installed POM now declares all runtime deps (jetty-server, jetty-proxy, jetty-servlet, jetty-servlets, httpclient5, commons-cli, jackson-databind, slf4j, logback, jsch, prometheus) while the main jar stays thin (0 bundled Jetty classes).2. Auto-publish to Maven Central
The
central-publishing-maven-pluginhad noautoPublish, so it defaults to a manual release:mvn deployonly uploads a pending/validated deployment that then needs a "Publish" click in the Central Portal. That's why the 4.8 publish workflow ran green but 4.8 never showed up on Central.Fix:
autoPublish=true+waitUntil=published, so a deploy from either the tag-triggeredrelease.ymlor the manualPublish to Maven Centralworkflow actually releases to Central.The 4.8 already uploaded to the Central Portal was built before fix #1, so it has the broken dependency-reduced POM. Since Central versions are immutable, please drop that pending 4.8 deployment in the portal before publishing. After merging this PR, publish a corrected build (re-run the publish for 4.8 if the pending one is dropped, or tag 4.9) — it will now be both thin and have a complete POM, and will publish automatically.
Summary by CodeRabbit