FrankChen021 commented on PR #20375:
URL: https://github.com/apache/druid/pull/20375#issuecomment-5724954929

   This PR is being closed as incompatible with the current Druid dependency 
graph. The reserved head remains `a139cabdf4b3ef6656426f856479573f6cf5e086` 
(base `master` at `2fed7ca11d9852412ce76798a3fa150ddae9afdb`). The complete 
diff is one version-only edit in `services/pom.xml`: 
`org.apache.maven.resolver:maven-resolver-util` `1.3.1` -> `2.0.23`.
   
   ## CI diagnosis
   
   The live rollup for this exact head is 27 completed CheckRuns: 19 `SUCCESS`, 
7 `FAILURE`, 1 `SKIPPED`, and 0 StatusContexts. The seven failures are 
PR-caused and deterministic, so no rerun was requested:
   
   - `packaging-check (25) / packaging-check-jdk25`, `static-checks-maven`, 
`strict-compilation`, and `openrewrite` all fail Maven Enforcer 
`RequireUpperBoundDeps` with the exact error `Require upper bound dependencies 
error for org.apache.maven.resolver:maven-resolver-api:1.3.1`. The paths 
contain the old `maven-resolver-connector-basic`, 
`maven-resolver-transport-http`, `maven-resolver-impl`, `maven-resolver-spi`, 
and `maven-resolver-provider:3.6.0`, while the changed util brings 
`maven-resolver-api:2.0.23`.
   - `unit tests / unit tests(main) (25, R*,B*,P*) / test-jdk25-[R*,B*,P*]` 
reports 71,576 tests run, 69,446 passed, 2,118 skipped, and 12 failed. All 12 
`PullDependenciesTest` errors are `java.lang.NoClassDefFoundError: 
org/eclipse/aether/scope/SystemDependencyScope`, caused by 
`java.lang.ClassNotFoundException: 
org.eclipse.aether.scope.SystemDependencyScope`.
   - `docker-tests / Run Docker tests` and `web-checks / web-checks` fail the 
same runtime path during `pull-deps`: `MavenRepositorySystemUtils.newSession` 
-> `PullDependencies.getRepositorySystemSession(PullDependencies.java:212)` -> 
`java.lang.NoClassDefFoundError: 
org/eclipse/aether/scope/SystemDependencyScope`, followed by `Process exited 
with an error: 1`.
   
   The failed-step logs and the published `unit-test-reports-jdk25-b0ecf7da` 
and `web-checks-logs-6452e6ad` artifacts were inspected. The unit report 
independently records `PullDependenciesTest` as 12 errors with the same missing 
class. The web-checks test suites themselves passed (159 suites, 786 tests, 247 
snapshots); the failure is the subsequent Resolver-backed `pull-deps` step.
   
   ## Published release inventory and transitions
   
   Maven Central metadata was used as the source of truth for actually 
published `maven-resolver-util` artifacts. There are 73 published versions 
inclusive of the source and target:
   
   ```text
   1.3.1, 1.3.2, 1.3.3, 1.4.0, 1.4.1, 1.4.2,
   1.6.1, 1.6.2, 1.6.3, 1.7.0, 1.7.1, 1.7.2, 1.7.3,
   1.8.0, 1.8.1, 1.8.2,
   1.9.0, 1.9.1, 1.9.2, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8,
   1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16,
   1.9.17, 1.9.18, 1.9.19, 1.9.20, 1.9.21, 1.9.22, 1.9.23,
   1.9.24, 1.9.25, 1.9.26, 1.9.27,
   2.0.0-alpha-1, 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-5,
   2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0-alpha-10,
   2.0.0-alpha-11, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5,
   2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.13, 2.0.14,
   2.0.15, 2.0.16, 2.0.17, 2.0.18, 2.0.20, 2.0.21, 2.0.22, 2.0.23
   ```
   
   The omitted tags `1.5.0`, `1.9.3`, `1.9.9`, `2.0.0-alpha-4`, 
`2.0.0-alpha-9`, `2.0.12`, and `2.0.19` were not published 
`maven-resolver-util` artifacts and are not counted. Every adjacent published 
transition in the inventory was reviewed through its Central POM and available 
Resolver release/tag history. The 1.x transitions retain the aligned 1.x module 
family, with the official compatibility document recording the 
`RepositoryLayout` SPI binary incompatibility introduced at 1.8.0. The `1.9.27` 
-> `2.0.0-alpha-1` transition is the major migration boundary; the alpha, GA, 
and subsequent 2.0.x transitions were reviewed for the cumulative target 
effect, including session, transport, repository-key, checksum, locking, and 
provenance changes.
   
   The official Resolver compatibility guidance says major version changes do 
not provide backward compatibility and that API, SPI, Util, implementation, 
connector, and transport modules used outside Maven must use the same version. 
Resolver 2.x guidance also says `ServiceLocator` integration is 
deprecated/dropped, the old default-session pattern can leak resources, and 
consumers should use `RepositorySystem#createSessionBuilder`/`CloseableSession`.
   
   ## Compatibility verdicts
   
   - **API/ABI — INCOMPATIBLE.** Resolver 2.0.23 adds `SystemDependencyScope` 
and session-builder APIs, while the 2.0 implementation no longer contains 
`org.eclipse.aether.impl.DefaultServiceLocator`. Druid directly imports and 
calls `DefaultServiceLocator`, 
`MavenRepositorySystemUtils.newServiceLocator()`, and 
`MavenRepositorySystemUtils.newSession()` in 
`services/src/main/java/org/apache/druid/cli/PullDependencies.java` and mirrors 
them in `PullDependenciesTest`.
   - **Runtime — INCOMPATIBLE.** The exact-head unit, web, and Docker failures 
all fail at the Resolver session construction path with the missing 
`SystemDependencyScope` class.
   - **Configuration — INCOMPATIBLE.** Resolver 2.x changes session/transport 
configuration and introduces repository-key behavior; the current Druid code 
has no migration for those settings.
   - **Serialization/wire — UNRESOLVED.** No Druid serialized payload is 
changed by this one-line diff, but Resolver 2.x changes checksum/tracking and 
transport behavior; there is no migration or compatibility validation for 
persisted Resolver metadata or remote interactions.
   - **Persistence — INCOMPATIBLE.** Resolver 2.x changes local-repository 
provenance and repository-key semantics; its documentation recommends starting 
with a new empty local repository when the key function changes. Druid’s 
`pull-deps` uses the local repository for extension resolution.
   - **Clients — INCOMPATIBLE.** Druid’s `services` and `server` modules 
hard-code Resolver 1.3.1 transport/connector/implementation usage and 
`maven-resolver-provider:3.6.0`; the provider is tied to Maven 3.6.0 and keeps 
the 1.x Resolver line. Moving to the 2.x-compatible provider path is a Maven 
integration migration, not a util-only update.
   - **Transitive dependencies — INCOMPATIBLE.** The current graph 
intentionally mixes Resolver 1.3.1 siblings with Util 2.0.23, which is exactly 
what Enforcer rejects. Resolver 2.0.23 also replaces the published 
`maven-resolver-transport-http` artifact with `maven-resolver-transport-apache`.
   - **Licenses — UNRESOLVED.** The current `licenses.yaml` records the 1.3.1 
Resolver modules, HTTP transport, and Maven Resolver Provider 3.6.0. A real 2.x 
migration adds/changes the Apache transport and its HTTP-client dependency 
surface and changes the provider/Maven surface, requiring a fresh license 
inventory.
   - **Extension/plugin SPI — INCOMPATIBLE.** Druid directly registers Resolver 
connector and transporter factories and relies on `DefaultServiceLocator`; 
Resolver’s official 2.x guidance documents the ServiceLocator removal and 
major-version SPI compatibility boundary.
   
   The bounded repair would require coordinated changes across 
`services/pom.xml`, `server/pom.xml`, 
`services/src/main/java/org/apache/druid/cli/PullDependencies.java`, 
`services/src/test/java/org/apache/druid/cli/PullDependenciesTest.java`, 
dependency/provider selection, transport imports/artifacts, 
local-repository/session behavior, license records, and full validation. That 
is materially larger and riskier than this reserved one-line dependency bump, 
so it was not attempted. No files were changed, no commit was made, and no push 
or CI rerun was performed.
   
   Closing this PR is the safe action for the reserved head. No merge was 
performed.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to