3.3.2 release is unresolvable: POM depends on `databricks-jdbc-core:3.3.2` which was not published to Maven Central

[o-shevchenko]

Summary

The com.databricks:databricks-jdbc:3.3.2 artifact published to Maven Central today (2026-04-28) cannot be resolved. Its POM declares a single compile dependency on com.databricks:databricks-jdbc-core:3.3.2, but that artifact was never published — the com.databricks:databricks-jdbc-core group/artifact does not exist on Maven Central at all.

This breaks any consumer that bumps from 3.3.1 → 3.3.2.

Reproduction

Minimal Gradle build:

repositories { mavenCentral() }
dependencies { implementation("com.databricks:databricks-jdbc:3.3.2") }

Resolution fails with:

Could not find com.databricks:databricks-jdbc-core:3.3.2.
Required by:
    root project > com.databricks:databricks-jdbc:3.3.2

Maven produces the equivalent error.

Evidence

• Published POM: https://repo1.maven.org/maven2/com/databricks/databricks-jdbc/3.3.2/databricks-jdbc-3.3.2.pom — declares dependency on databricks-jdbc-core:3.3.2.
• Missing artifact directory: https://repo1.maven.org/maven2/com/databricks/databricks-jdbc-core/ → 404. The artifact has never been published under this coordinate.
• 3.3.1's POM had no such dependency (the published jar was self-contained), which is why 3.3.1 resolves fine.

Likely cause

The multi-module split landed in #1243 (merged 2026-03-02), introducing jdbc-core/, assembly-thin/, and assembly-uber/ modules. 3.3.1 (#1281) released without issue, suggesting the release workflow correctly published a self-contained artifact under the databricks-jdbc coordinate. 3.3.2 (#1419) appears to have published the parent/wrapper POM by mistake — one that points at a jdbc-core module that isn't itself promoted to Maven Central.

Suggested fix

Either:

1. Publish com.databricks:databricks-jdbc-core:3.3.2 to Maven Central (and document it as a public coordinate going forward), or
2. Re-release as 3.3.3 with the databricks-jdbc artifact restored to a self-contained jar (no transitive dependency on the internal core module), matching 3.3.1's behavior.

Yanking 3.3.2 isn't possible on Maven Central, so a follow-up release is the practical path.

Impact

3.3.2 is currently unusable for any downstream consumer. Dependabot/Renovate users will see CI failures on the auto-generated bump PRs.

[vikrantpuppala]

taking a look

[o-shevchenko]

Thanks @vikrantpuppala
Looks like there's a serious gap in the testing and release process that allowed a jar with an unresolvable POM to be published to Maven Central. A post-publish resolution check, a clean Maven/Gradle build that declares the artifact and resolves it against Central from a fresh cache would close that gap.

[vikrantpuppala]

Apologies for the inconvenience @o-shevchenko.

The primary root cause was that we've changed our releases processes to improve the security posture of our artifacts (which is also the cause for the delayed release) but this inadvertently exposed an existing misconfiguration in the artifact generation process. Agreed that there needs to be additional validation which we will work on adding.