Repository navigation
fix: sign and attach sources and javadoc in 1.x releases - #1707
Merged
Merged
Conversation
This reverts commit 2c0fc19.
…r-1.9.5" This reverts commit 9de28dd.
The 1.9.5 release run uploaded only each module's pom and jar, so the Central Portal rejected the deployment with a 400. The signatures, sources and javadoc jars Maven Central requires were never produced. On 1.x those came from profiles activated by the performRelease property: release-sign-artifacts in this pom for signing, and Maven's own release-profile for sources and javadoc. maven-release-plugin 3.x no longer sets performRelease, and the plugin version here was not pinned, so the current runner picked up 3.x and neither profile ran. 1.9.4 was released in 2024 with an older plugin. main and 2.1.x pin maven-release-plugin 3.1.1 and name their release profile explicitly. Do the same here: pin 3.1.1, set releaseProfiles to serverless-java-container-release, and replace release-sign-artifacts with main's profile (gpg 3.2.7, javadoc, sources 3.3.1), so the three lines release the same way. Verified locally on JDK 8 by deploying with the profile to a file repository: every library module now produces jar, sources and javadoc, and the archetypes jar and sources, matching what 3.0.3 shipped. Signing was skipped locally and runs on the release runner with the same plugin version and key that signed 3.0.3 and 2.1.6.
ckawl
marked this pull request as ready for review
October 16, 2026 03:01
vicheey
approved these changes
Oct 16, 2026
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
2 participants
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.
Issue #, if available:
Description of changes:
The 1.9.5 release run failed at "Upload to Central Publisher Portal" with a 400. The release step before it only uploaded each module's pom and jar. The signatures, sources jars and javadoc jars that Maven Central requires were never produced, so the Central Portal rejected the deployment. Nothing was published.
Cause. On 1.x, those files came from profiles activated by the
performReleaseproperty:release-sign-artifactsin this pom for signing, and Maven's built-inrelease-profilefor sources and javadoc. maven-release-plugin 3.x no longer setsperformRelease. The plugin version on 1.x was not pinned, so the current runner resolved 3.x and neither profile ran. 1.9.4 was released in 2024 with an older plugin.Fix. main and 2.1.x already pin maven-release-plugin 3.1.1 and name their release profile explicitly. This does the same on 1.x:
releaseProfilestoserverless-java-container-releaserelease-sign-artifactswith main'sserverless-java-container-releaseprofile (maven-gpg-plugin 3.2.7, javadoc, maven-source-plugin 3.3.1)It also reverts the two commits the failed run pushed ("prepare release 1.9.5" and "prepare for next development iteration"), so 1.x is back to its state before the run. The
aws-serverless-java-container-1.9.5tag the run pushed is deleted separately.Testing
On JDK 8, deploying with the release profile to a local file repository produces jar, sources and javadoc for every library module, and jar and sources for the archetypes. That is the same set 3.0.3 shipped. Signing was skipped locally because this machine has no gpg agent. On the release runner it uses the same plugin version and key that signed 3.0.3 and 2.1.6.
By submitting this pull request