hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayush Saxena (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-17288) Use shaded guava from thirdparty
Date Thu, 01 Oct 2020 07:50:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205340#comment-17205340
] 

Ayush Saxena edited comment on HADOOP-17288 at 10/1/20, 7:49 AM:
-----------------------------------------------------------------

Transitive dependency as the dependencies which hadoop pulls up, on which hadoop depends.
Like {{mockserer-core}} is one. If you see the {{hadoop-project/pom.xml}}, whichever dependency
has excluded {{Guava}}, requires guava.

Ideally if the downstream has to upgrade guava, then this patch has no meaning. The basic
requirement itself is that the downstream should not need to upgrade guava. 
If the transitive dependency, say {{x}} is a dependency of {{hadoop-common}}, which is compatible
with the guava version of the downstream project they can exclude it, and I think things should
work fine?

If there are dependencies with higher version of Guava, (need to analyse), which aren't compatible
with guava version of downstream projects. Then we might need to shade them as well? May be
{{curator}} can be one of those. 

Let me know, if you have any idea/suggestion or different approach which may make things better


was (Author: ayushtkn):
Transitive dependency as the dependencies which hadoop pulls up, on which hadoop depends.
Like {{mockserer-core}} is one. If you see the {{hadoop-project/pom.xml}}, whichever dependency
has excluded {{Guava}}, requires guava.

Ideally if the downstream has to upgrade guava, then this patch has no meaning. The basic
requirement itself is that the downstream should not need guava. 
If the transitive dependency, say {{x}} is a dependency of {{hadoop-common}}, which is compatible
with the guava version of the downstream project they can exclude it, and I think things should
work fine?

If there are dependencies with higher version of Guava, (need to analyse), which aren't compatible
with guava version of downstream project. Then we might need to shade them as well? May be
{{curator}} can be one of those.

Let me know, if you have any idea/suggestion or different approach which may make things better

> Use shaded guava from thirdparty
> --------------------------------
>
>                 Key: HADOOP-17288
>                 URL: https://issues.apache.org/jira/browse/HADOOP-17288
>             Project: Hadoop Common
>          Issue Type: Sub-task
>            Reporter: Ayush Saxena
>            Assignee: Ayush Saxena
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 3.4.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Use the shaded version of guava in hadoop-thirdparty



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message