[
https://issues.apache.org/jira/browse/HADOOP-20016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137922#comment-18137922
]
ASF GitHub Bot commented on HADOOP-20016:
-----------------------------------------
joseluisll commented on PR #8894:
URL: https://github.com/apache/hadoop/pull/8894#issuecomment-6628265934
Thanks @pan3793 for the review.
The version pin you suggest is already in this PR: `hadoop-project/pom.xml`
now manages `jetty-http` at `${jetty.version}` in `dependencyManagement`.
The module declarations exist because `HttpServer2`,
`ShuffleChannelHandler`, `TestJettyHelper` (HttpFS) and `SLSWebApp` import
`org.eclipse.jetty.http.*` directly, but only get it through `jetty-server`. My
main concern was not to change what downstream projects resolve. That's why
they are `optional` (`provided` in hadoop-sls):
- With `optional`, downstream resolution is identical to trunk. I compared
the dependency trees of sample downstream projects to check this.
- At plain compile scope it was not. A project with `jetty-client` 9.4.40
next to `hadoop-common` resolved `jetty-http` 9.4.58 instead of 9.4.40, because
Maven's nearest-wins picked Hadoop's declaration.
The declarations aren't strictly needed for the Jetty 12 port, though:
`jetty-server` 12 still brings `jetty-http`. If you prefer, I'll drop them and
keep only the `dependencyManagement` entry and the Log/context-cast cleanup.
Downstream resolution stays the same either way.
> HADOOP - Declare jetty-http where it is imported, and drop Jetty's Log and
> context cast
> ---------------------------------------------------------------------------------------
>
> Key: HADOOP-20016
> URL: https://issues.apache.org/jira/browse/HADOOP-20016
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: mapreduce
> Reporter: Jose Luis López
> Assignee: Jose Luis López
> Priority: Minor
> Labels: pull-request-available
>
> *Scope*:
> * hadoop-project/pom.xml: manage jetty-http at ${jetty.version}. It is not
> managed today.
> * hadoop-mapreduce-client-shuffle/pom.xml: ShuffleChannelHandler imports
> org.eclipse.jetty.http.HttpHeader. Declare org.eclipse.jetty:jetty-http,
> optional.
> * hadoop-common/pom.xml: HttpServer2 and McpHttpServer import
> org.eclipse.jetty.http.*. Declare jetty-http at compile scope, optional.
> * hadoop-hdfs-httpfs/pom.xml: TestJettyHelper imports
> org.eclipse.jetty.http.*. Declare jetty-http, optional.
> * hadoop-sls/pom.xml: SLSWebApp imports org.eclipse.jetty.http.*. Declare
> jetty-http with scope provided, like the module's jetty-server.
> * FSMainOperationsBaseTest, ViewFileSystemTestSetup, ViewFsTestSetup and
> TestAuthenticationSessionCookie: they logged through
> org.eclipse.jetty.util.log.Log, which Jetty 10 and later no longer have. Log
> through SLF4J instead.
> * HttpServer2#inferMimeType: drop the cast to a Jetty context, since
> ServletContext has getMimeType.
> *Why*: these modules compile against jetty-http that they get only
> transitively, through jetty-server.
> *Why optional*: it keeps the declaration for compiling each module without
> passing it on, so what downstream projects resolve does not change. At plain
> compile scope it did: Maven's nearest-wins mediation picked Hadoop's
> jetty-http over another one at the same depth, and a project with
> jetty-client 9.4.40 next to hadoop-common resolved jetty-http 9.4.58 instead
> of 9.4.40. In the shuffle handler, trunk already resolves jetty-http at
> compile scope (through the NodeManager and mapreduce-client-common); optional
> keeps that, whereas provided would change it (review on PR #8699). It is not
> copied into the mapreduce lib directory.
> *Impact on Jetty 9*: none. jetty-http already resolves at 9.4.58 in each
> module, and the logging and cast changes behave the same.
> *Downstream*: none. Projects that depend on these modules keep getting
> jetty-http through jetty-server, as today.
> *CI*: touches hadoop-project, so a full build.
> *PR*: https://github.com/apache/hadoop/pull/8894
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
