Fix Java SDK RC2 blockers: source packaging, jar LICENSE/NOTICE, BOM gap#69582
Merged
jason810496 merged 8 commits intoJul 8, 2026
Merged
Conversation
Only gradle-wrapper.jar was excluded from the sourceRelease tarball (LEGAL-570), but gradlew, gradlew.bat, and gradle-wrapper.properties still shipped, drawing a binding -1 in the 1.0.0-beta1 RC2 vote. The wrapper stays tracked in git; only the git-archive output used by sourceRelease now omits it. Document both ways to build an extracted source package without the wrapper, add a release-verification checklist, and add a vote-email template with the full 8-artifact staged list so future RCs don't repeat the RC2 feedback.
Staged convenience-binary jars (main, sources, javadoc, test-fixtures) were missing META-INF/LICENSE and META-INF/NOTICE, violating ASF release policy for distributed binaries. Builds were also not byte-reproducible: jar entries carried wall-clock timestamps, blocking GitHub-driven publishing. Centralizing both fixes in the airflow-jvm-conventions plugin, applied by every jar-producing module (sdk, jul, log4j2, slf4j, jpl, processor, plugin), covers all modules without per-module duplication.
The BOM constrained sdk, jul, log4j2, processor, and slf4j but not jpl, even though jpl is published to Nexus and the bundled example module depends on it. Consumers pulling in jpl via the BOM alone had no version constraint to resolve against.
airflow-sdk-gradle-plugin publishes under the same org.apache.airflow Maven coordinate convention as the other SDK artifacts, but was left out of the BOM's constraints when airflow-sdk-jpl was added — the same gap the jpl fix was closing. Consumers importing airflow-sdk-bom still got no version pin for the plugin artifact.
uranusjr
reviewed
Jul 8, 2026
uranusjr
force-pushed
the
verify/java-sdk-rc3-integration
branch
from
092a209 to
96299bf
Compare
uranusjr
approved these changes
Jul 8, 2026
phanikumv
reviewed
Jul 8, 2026
| } | ||
| } | ||
|
|
||
| tasks.named("check") { dependsOn(verifyBomCoverage) } |
Contributor
There was a problem hiding this comment.
verifyBomCoverage runs as a dependency of check, but the Java SDK CI job runs ./gradlew test (ci-amd.yml / ci-arm.yml), and test doesn't trigger check.
So this guard won't fire on a PR that adds a published module and forgets the BOM ,but CI stays green. It does still catch it on ./gradlew build locally and at the release "Build from source" step, so the release itself is protected.
If we want the earlier signal, switching the CI job to ./gradlew check (or adding verifyBomCoverage to the test job) would close the gap.
Member
Author
There was a problem hiding this comment.
Sure, but I will do this in follow-up as this is non-blocking and Jarek approve the PR so I think we can start the RC3.
potiuk
approved these changes
Jul 8, 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
4 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.
Why
RC2 of the Java SDK 1.0.0-beta1 vote cannot pass: Jarek cast a binding -1 because
the Gradle wrapper still ships in the source-release tarball, and RC2
verification separately found the staged convenience-binary jars are missing
META-INF/LICENSE/NOTICE, builds aren't byte-reproducible, and the BOMdoesn't manage the
jplartifact's version. All three must land before RC3.What
gradlew,gradlew.bat, andgradle/wrapperfrom thegit archive-based source tarball via.gitattributesexport-ignore(the wrapper stays tracked in git — only therelease tarball omits it). Document both extracted-source build paths, and
add "Verifying a release" and vote-email template sections to
java-sdk/README.md.META-INF/LICENSE/NOTICEintoevery published jar and make archives byte-reproducible (fixed timestamps,
file ordering, permissions), centralized once in the
airflow-jvm-conventionsconvention plugin so it covers every jar-producing module.
airflow-sdk-jplto the BOM's dependencyconstraints so consumers can depend on it without pinning a version
explicitly.
Verification
Each change was implemented and verified independently (source-archive content
checks, jar inspection plus reproducibility hash diffs, and a BOM resolution
smoke test) and passed its own review pass before being combined here; see
commits 5a03a02, 0231511, and 1f400a8 for per-change detail.
Was generative AI tooling used to co-author this PR?