[
https://issues.apache.org/jira/browse/HADOOP-20016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137705#comment-18137705
]
ASF GitHub Bot commented on HADOOP-20016:
-----------------------------------------
pan3793 commented on PR #8894:
URL: https://github.com/apache/hadoop/pull/8894#issuecomment-6621102120
> Declare jetty-http where it is imported, and drop Jetty's Log and context
cast
I think it's two topics, though both are small enough that I don't worry
about mixing them in one PR. +1 for the latter, but I'm not sure about the
intention of the former; I know someone calls that best practice, but it seems
your purpose is to make the version alignment? If so, I would not do it in this
way, we should pin the version in parent pom.xml `dependencyManagement` so that
all sub-modules use the same version.
> 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]
