[
https://issues.apache.org/jira/browse/HADOOP-14284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962810#comment-15962810
]
Sean Busbey commented on HADOOP-14284:
--------------------------------------
Sorry, late on these
{code}
diff --git hadoop-client-modules/hadoop-client-api/pom.xml
hadoop-client-modules/hadoop-client-api/pom.xml
164 <!-- Exclude config keys for Guava that is
shaded in hadoop-common -->
165 <exclude>com/google/common/*</exclude>
{code}
{code}
diff --git hadoop-client-modules/hadoop-client-minicluster/pom.xml
hadoop-client-modules/hadoop-client-minicluster/pom.xml
691 <!-- Exclude config keys for Guava that is
shaded in hadoop-common -->
692 <exclude>com/google/common/*</exclude>
{code}
{code}
diff --git hadoop-client-modules/hadoop-client-runtime/pom.xml
hadoop-client-modules/hadoop-client-runtime/pom.xml
237 <!-- Exclude config keys for Guava that is
shaded in hadoop-common -->
238 <exclude>com/google/common/*</exclude>
{code}
Won't all of these have been rewritten by the third party module? Otherwise
mustn't whatever is in hadoop-common be referring to a non-relocated Guava?
Related to the above, I don't see where the modules that now depend on
shaded-third-party are changed to reference the relocated version of Guava. We
can do it either in the source code or in the build, but I don't see us doing
either ATM.
For example, [apache avro does this by making a temp jar with non-relocated
classes they reference, then doing the relocation for both the classes and
their references in the user facing
module|https://github.com/apache/avro/commit/f7ec67996b66444f9de2284d1ddfaa66297ba51e].
Apache HBase does the update-the-source approach for their relocated Google
Protobuf. (There's not a simple thing to point at for that example,
unfortunately. [the README for the module that does the
relocation|https://github.com/apache/hbase/blob/48439e57201ee3be5eb12e6187002501af305a35/hbase-protocol-shaded/README.txt]
is the closest, since it at least has pointers to what's going on and the
commits involved.)
> Shade Guava everywhere
> ----------------------
>
> Key: HADOOP-14284
> URL: https://issues.apache.org/jira/browse/HADOOP-14284
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Affects Versions: 3.0.0-alpha3
> Reporter: Andrew Wang
> Assignee: Tsuyoshi Ozawa
> Priority: Blocker
> Attachments: HADOOP-14238.pre001.patch, HADOOP-14284.002.patch,
> HADOOP-14284.004.patch
>
>
> HADOOP-10101 upgraded the guava version for 3.x to 21.
> Guava is broadly used by Java projects that consume our artifacts.
> Unfortunately, these projects also consume our private artifacts like
> {{hadoop-hdfs}}. They also are unlikely on the new shaded client introduced
> by HADOOP-11804, currently only available in 3.0.0-alpha2.
> We should shade Guava everywhere to proactively avoid breaking downstreams.
> This isn't a requirement for all dependency upgrades, but it's necessary for
> known-bad dependencies like Guava.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
