Fix unresolvable 3.3.2 Maven Central POM for uber jar#1432
Merged
vikrantpuppala merged 1 commit intomainfrom Apr 29, 2026
Merged
Fix unresolvable 3.3.2 Maven Central POM for uber jar#1432vikrantpuppala merged 1 commit intomainfrom
vikrantpuppala merged 1 commit intomainfrom
Conversation
The uber jar's published POM declared a compile dependency on the internal databricks-jdbc-core coordinate, which is never published to Maven Central. Downstream consumers bumping to 3.3.2 saw: Could not find artifact com.databricks:databricks-jdbc-core:jar:3.3.2 Root cause: flatten-maven-plugin's <dependencies>expand</dependencies> rewrites direct + transitive deps to a flat list, but does not drop a direct dep that points at an unpublished sibling module. The shaded uber jar contains every runtime class, so the published POM should declare zero compile deps — switch flatten to <dependencies>remove</dependencies>. Verified by re-running the release-workflow build sequence locally and resolving com.databricks:databricks-jdbc:3.3.2 against a repo that omits both jdbc-core and the parent POM (mimicking Maven Central state). With the fix, resolution succeeds; without it, it fails identically to issue #1431. Fixes #1431 Co-authored-by: Isaac Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
gopalldb
approved these changes
Apr 29, 2026
vikrantpuppala
added a commit
that referenced
this pull request
Apr 29, 2026
## Summary Recovers from the broken 3.3.2 Maven Central release (#1431) by cutting 3.3.3 with the source-side fix from #1432. 3.3.2 published a POM that declared an unresolvable transitive dependency on `com.databricks:databricks-jdbc-core:3.3.2` (an internal coordinate that is not published to Maven Central). Downstream consumers bumping to 3.3.2 saw `Could not find artifact com.databricks:databricks-jdbc-core:jar:3.3.2`. Yanking from Maven Central is not possible, so 3.3.3 is the recovery release. ## Changes - Version bump 3.3.2 → 3.3.3 across all POMs, the `DRIVER_VERSION` constant in `DriverUtil`, and assertion strings in `DriverUtilTest`, `DatabricksDatabaseMetaDataTest`, `DatabricksDriverFeatureFlagsContextTest`. - Move `NEXT_CHANGELOG.md` entries into `CHANGELOG.md` under `[v3.3.3]`. Reset `NEXT_CHANGELOG.md` to empty template. - Flip `development/.release-freeze.json` from `freeze: true` → `freeze: false`. - Update install snippet in `README.md`. ## Validation The post-#1432 release artifacts have been pre-validated end-to-end via a staging dry-run: 1. **Tagged `v3.3.3-rc1`** off the same commit pool as this release. 2. **Ran the `peco-databricks-jdbc` workflow with `staging-only=true`** (USER_MANAGED upload to Sonatype Central Portal). 3. **Sonatype validated the bundle on attempt 2** — full validators (signatures, checksums, POM completeness, namespace ownership, file naming) all green. 4. **Inspected the staged POMs:** - Uber POM: 0 dependencies, no `<parent>`, all required Maven Central metadata present. Byte-shape-equivalent to the working 3.3.1 POM. - Thin POM: 57 runtime deps, no `databricks-jdbc-core`, no `databricks-jdbc-parent` references. Same shape as published 3.3.1 thin. 5. **Staged the bundle into a local file repo** and verified `mvn dependency:resolve` of `com.databricks:databricks-jdbc:3.3.3-rc1` succeeds — exactly the resolution that fails for 3.3.2. 6. **Built a probe project that imports the staged uber jar**, loaded the driver via JDK ServiceLoader, opened a real connection to the dogfood workspace, and round-tripped a `SELECT` query. Output: ``` Driver class: com.databricks.client.jdbc.Driver Driver version: 3.3 DriverVersion: 3.3.3-rc1 Row: one=1 msg=hello PROBE_OK ``` 7. **Dropped the rc1 deployment** in the Central Portal (deployment ID `a83f922f-9750-4a14-b697-a6005a6fc858`) — never reached `repo1.maven.org`. ## After merge 1. Tag `v3.3.3` on this commit. 2. Run `peco-databricks-jdbc` workflow off `main` of `databricks/secure-public-registry-releases-eng` with `ref=v3.3.3`, `dry-run=false`, `staging-only=false`. 3. Confirm 3.3.3 lands on Maven Central and resolves cleanly. ## Test plan - [x] All version strings bumped in lockstep (verified by `git grep "3\.3\.2"` returning only CHANGELOG hits). - [x] Local build of jdbc-core + assembly-uber succeeds with the bumped version. - [x] `assembly-uber/.flattened-pom.xml` confirmed to have 0 `<dependencies>` after build. - [x] End-to-end rc1 validation as described above. - [ ] Post-merge: live publish run on Maven Central. This pull request and its description were written by Isaac. --------- Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
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.
Summary
databricks-jdbc-core:3.3.2which was not published to Maven Central #1431. The uber jar's published 3.3.2 POM on Maven Central declares a compile dependency oncom.databricks:databricks-jdbc-core:3.3.2, which is never published. Consumers bumping to 3.3.2 fail to resolve.flatten-maven-pluginforassembly-uberfrom<dependencies>expand</dependencies>to<dependencies>remove</dependencies>. The shaded uber jar bundles every runtime class, so the published POM should declare zero compile deps..flattened-pom.xmlis and why the dependencies must be stripped.Why
expandwas wrongflatten-maven-plugin'sexpandrewrites direct + transitive deps into a flat list, but it doesn't strip a direct dependency that points at an unpublished sibling module.databricks-jdbc-coreis built locally during the release workflow'smvn install -pl jdbc-core -amstep but is intentionally not deployed to Maven Central. The 3.3.1 release happened to publish a POM with no<dependencies>section (via the prior release pipeline); 3.3.2 was the first release through the newpeco-databricks-jdbc.ymlworkflow, and that workflow uploadsassembly-uber/.flattened-pom.xmlas the published POM — which still namesdatabricks-jdbc-coreas a compile dep.Test plan
mvninvocations onmain(v3.3.2 source) and confirmingassembly-uber/.flattened-pom.xmlhad the brokendatabricks-jdbc-coredep.mvn dependency:resolveofcom.databricks:databricks-jdbc:3.3.2against a local repo withjdbc-coreremoved fails with the same error reported in 3.3.2 release is unresolvable: POM depends ondatabricks-jdbc-core:3.3.2which was not published to Maven Central #1431..flattened-pom.xmlhas no<dependencies>and no<parent>, byte-equivalent in shape to the published 3.3.1 POM.mvn dependency:resolveofcom.databricks:databricks-jdbc:3.3.2against a local repo missing bothdatabricks-jdbc-coreanddatabricks-jdbc-parentsucceeds.Companion change
A workflow-side change is also needed in
databricks-eng/secure-public-registry-releases-engso the thin JAR's published POM is sourced fromdependency-reduced-pom.xmlinstead of.flattened-pom.xml. The thin POM happened to publish correctly for 3.3.1 due to flatten-plugin behaviour but is structurally fragile in the same way — that PR is filed separately.NO_CHANGELOG=false
OVERRIDE_FREEZE=true
This pull request and its description were written by Isaac.