FrankChen021 commented on PR #19897: URL: https://github.com/apache/druid/pull/19897#issuecomment-5199786141
CLOSED_HIGH_EFFORT I reviewed this PR at head `82ce091804ee099d9d971b2414a3144d361100cb` against parent-verified upstream master `95e2c40304d87a07f76c58acccad70cc0a22d637`. ## Verified applicability and root cause - Master still contains the affected `services/pom.xml` declaration at `org.apache.maven.resolver:maven-resolver-spi:1.3.1`; the exact PR changes only that artifact to `2.0.21`. The upgrade is therefore still applicable, and this closure is not based on age, conflict, or path removal. - The exact PR head fails because Resolver 2.0.21 is not a drop-in standalone replacement for the Resolver 1.3.1 family. The 2.0.21 `maven-resolver-spi` JAR no longer contains `org.eclipse.aether.spi.locator.ServiceLocator`, while the 1.3.1 SPI JAR does. Druid services currently compiles `PullDependencies` through `MavenRepositorySystemUtils.newServiceLocator()` and `DefaultServiceLocator` at `services/src/main/java/org/apache/druid/cli/PullDependencies.java:184-187`. - The exact-head CI logs repeatedly report `/services/src/main/java/org/apache/druid/cli/PullDependencies.java:[185,12] cannot access org.eclipse.aether.spi.locator.ServiceLocator` and `class file ... not found` in CodeQL, web checks, all JDK 25 unit shards, and all four QTest shards. - Static checks independently report the dependency convergence failure: `maven-resolver-spi:2.0.21` brings `maven-resolver-api:2.0.21`, while direct `maven-resolver-api`, `maven-resolver-connector-basic`, `maven-resolver-transport-http`, `maven-resolver-util`, and `maven-resolver-impl` remain `1.3.1`; `maven-resolver-provider:3.6.0` also brings Resolver `1.3.1`. This fails `RequireUpperBoundDeps` in static checks, strict compilation, packaging, and OpenRewrite. ## Compatibility and migration evidence - Maven Resolver states that a major version change does not guarantee backward compatibility and that applications must keep API, SPI, Util, implementation, connectors, and transports on the same version: https://maven.apache.org/resolver/api-compatibility.html - The Resolver 1.x to 2.x migration guide calls out session lifecycle changes: clients managing Resolver should use `RepositorySystem` session builders and closeable sessions instead of the legacy `DefaultRepositorySystemSession` construction. Druid currently uses `MavenRepositorySystemUtils.newSession()` and stores the session for `PullDependencies`: https://maven.apache.org/resolver-archives/resolver-2.0.8/upgrading-resolver.html - The 2.0.21 release notes include transport, HTTP/3, path validation, resource-leak, concurrency, retry, and re-entrant-call changes. These are behavior changes in the extension dependency download path, not merely metadata: https://github.com/apache/maven-resolver/releases/tag/maven-resolver-2.0.21 - The 2.0.21 SPI artifact metadata depends on Resolver API `2.0.21`, while the existing Maven 3.6.0 provider is a Resolver 1.3.1 family consumer. Resolver project dependency metadata shows the expected 2.0.21 family alignment: https://maven.apache.org/resolver/maven-resolver-spi/dependencies.html - Resolver 2.0.21 publishes Apache-2.0 metadata. Druid currently has one `licenses.yaml` record for the resolver connector family with version `1.3.1` covering SPI, API, Util, and connector-basic, plus separate `1.3.1` records for HTTP transport and implementation. A coordinated upgrade would need corresponding maintained license metadata updates. - I found no Resolver-specific advisory in the Apache Maven security reports or the GitHub advisory search. That does not remove the compatibility failure. I verified that the PR diff does not directly change Druid query APIs, wire/serialization formats, stored segment or metadata formats, configuration schemas, or Druid extension interfaces. The affected runtime surface is the `pull-deps` extension/plugin dependency resolver, including repository transport, proxy, session, and local dependency layout; deployment compatibility and extension assembly behavior therefore require focused migration tests. No focused test can pass while the current classpath is uncompilable. ## Why this is high effort A safe fix is not a one-line version correction. It requires a coordinated Resolver family/provider migration across the services and server dependency graphs, a decision about replacing the Maven 3.6.0 provider with a compatible provider, adaptation of `PullDependencies` and its tests to the Resolver 2.x session/service-locator model, validation of extension download/proxy/transport behavior on supported Druid runtimes, and synchronized license metadata. The Dependabot branch is also not writable by maintainers (`maintainerCanModify=false`). I did not make a speculative partial fix or rebase; the PR is not conflicting. The future upgrade path is a dedicated coordinated Maven Resolver migration that updates all required resolver modules and provider together, then adds focused `PullDependencies` and extension assembly coverage before reopening a dependency bump. Relevant exact-head checks: - CodeQL: https://github.com/apache/druid/actions/runs/31057875603 - Static Checks CI: https://github.com/apache/druid/actions/runs/31057876321 - Unit and Integration tests CI: https://github.com/apache/druid/actions/runs/31057877224 - Static `RequireUpperBoundDeps`: https://github.com/apache/druid/actions/runs/31057876321/job/92479249825 - Packaging `RequireUpperBoundDeps`: https://github.com/apache/druid/actions/runs/31057876321/job/92479249826 - Web compile failure: https://github.com/apache/druid/actions/runs/31057876321/job/92479249790 - JDK 25 compile failure: https://github.com/apache/druid/actions/runs/31057877224/job/92479252498 - QTest compile failure: https://github.com/apache/druid/actions/runs/31057877224/job/92479252449 -- 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]
