You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Ayush Saxena (Jira)" <ji...@apache.org> on 2020/10/01 07:48:00 UTC

[jira] [Comment Edited] (HADOOP-17288) Use shaded guava from thirdparty

    [ 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:47 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 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


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}}, brings up guava in hadoop.

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