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

   Closing this upgrade because the current one-line version bump requires a 
repository-wide Jakarta EE migration, not a small dependency-PR fix.
   
   Evidence and root cause:
   
   - This PR changes only `guice.version` from 6.0.0 to 7.0.0 at head 
`9b2b22c86320ba9b3808a89557f46d3abc23bef9`, based directly on current `master` 
`841faf155f0b3b5b2cbf9a29ffab1aa3d20fbbc8`. Current `master` still uses Guice 
6.0.0, so the PR is neither stale nor already covered.
   - All checks are terminal: 22 failed, 3 succeeded, 2 skipped, and 1 neutral. 
The [static checks](https://github.com/apache/druid/actions/runs/30501122038), 
[unit/integration 
matrix](https://github.com/apache/druid/actions/runs/30501122195), and [CodeQL 
build](https://github.com/apache/druid/actions/runs/30501121879) fail after 
this bump. Static, packaging, OpenRewrite, strict-compilation, web, and CodeQL 
builds consistently report that `jakarta.servlet.ServletContextListener`, 
`jakarta.servlet.Filter`, and `jakarta.servlet.http.HttpServlet` are 
unavailable while compiling `druid-server`. The unit matrix additionally has 
cascading Guice `CreationException`/class-initialization failures and 
ultimately the same server compilation errors.
   - The authoritative [Guice 7.0 migration 
notes](https://github.com/google/guice/wiki/Guice700#jee-jakarta-transition) 
state that Guice 7 supports only `jakarta.inject`, `jakarta.servlet`, and 
`jakarta.persistence`, removes support for the corresponding `javax.*` APIs, 
and that Guice 6 was intentionally released as the migration bridge. Guice 6 
and 7 are otherwise described as identical.
   
   Why this is high effort rather than a surgical fix:
   
   - At this exact `master`, Druid has 411 
`javax.inject`/`javax.servlet`/`javax.persistence` import statements across 178 
Java source/test files and no corresponding `jakarta.*` imports. Affected areas 
include `server`, `extensions-core`, `indexing-service`, `sql`, 
`multi-stage-query`, `services`, `processing`, `extensions-contrib`, and 
`quidem-ut`.
   - The Druid runtime stack is still explicitly on Jetty EE8 servlet modules, 
Jersey 1.19.4, `javax.servlet-api` 4.0.1, and `javax.inject` 1. Guice Servlet 7 
instead declares `jakarta.servlet-api` 5.0.0 as its provided API, and Guice 
core 7 uses `jakarta.inject-api` 2.0.1. These are different package/type 
identities, so adding one missing JAR would not make the existing 
EE8/Jersey/servlet integration source- or binary-compatible.
   - Completing the upgrade safely therefore requires coordinated migration of 
injection and servlet APIs, server bootstrap/filter/listener code, Jersey/Jetty 
integrations, security extensions, public/resource method signatures, 
dependency exclusions and distribution metadata, plus focused unit, packaging, 
extension, HTTP/security, and end-to-end runtime tests. Mixing `javax.*` and 
`jakarta.*` servlet contracts would carry substantial runtime linkage, 
filter/listener registration, authentication, and extension compatibility risk.
   
   Other compatibility checks:
   
   - Java is not the blocker: Guice 7 remains Java 8 compatible, while current 
Druid builds with Java 25.
   - Guice 7 remains Apache License 2.0, so no new license blocker was found.
   - The Guice [GitHub security-advisory 
feed](https://github.com/google/guice/security/advisories) currently lists no 
repository advisories; this closure is for verified API incompatibility, not an 
unresolved advisory.
   
   Recommended future path: keep Guice 6.0.0 until a dedicated Jakarta EE 
migration updates the servlet/injection stack and downstream integrations 
together. After that migration is green across the full build, reopen the Guice 
7 upgrade as the final coordinated dependency step.
   
   No diagnostic or speculative commits were pushed.


-- 
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