[
https://issues.apache.org/jira/browse/BEAM-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927112#comment-15927112
]
ASF GitHub Bot commented on BEAM-1092:
--------------------------------------
GitHub user tgroh opened a pull request:
https://github.com/apache/beam/pull/2256
[BEAM-1092] Rollback global shading of Guava
Be sure to do all of the following to help us incorporate your contribution
quickly and easily:
- [ ] Make sure the PR title is formatted like:
`[BEAM-<Jira issue #>] Description of pull request`
- [ ] Make sure tests pass via `mvn clean verify`. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
- [ ] Replace `<Jira issue #>` in the title with the actual Jira issue
number, if there is one.
- [ ] If this contribution is large, please file an Apache
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.txt).
---
Revert PRs #2096 and #2249
PR #2096 has caused BigtableITs to fail, as of
https://builds.apache.org/job/beam_PostCommit_Java_MavenInstall/2906/
The `BigtableDataClient` has methods that return Guava types, e.g.
`sampleRowKeys` returns an `ImmutableList`, and we rewrite those calls to
reference the repackaged type, but we don't repackage the actual client
libraries; as a result when the JVM tries to find the
`sampleRowKeys(SampleRowKeysRequest) -> ImmutableList<SampleRowKeysResponse>`
it fails.
We can certainly not shade guava in the google-cloud-platform IOs module; I
believe it is also possible to repackage the appropriate Bigtable libraries to
ensure the return types of those methods are also repackaged. However,
`BigtableIO` uses classes that are defined in the `Bigtable` libraries, so we
would have to force our version on users.
@davorbonaci @aviemzur
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tgroh/beam no_repackage_gcp_io
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/beam/pull/2256.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2256
----
commit 506a2cfa0b730d9b1ec8ec07223797c697b061f1
Author: Thomas Groh <[email protected]>
Date: 2017-03-15T22:28:45Z
Revert "Increment shade-plugin version back to 3.0.0"
This reverts commit 8f7c320846b598dc650a7b786182f7cecdd9c601.
commit dcfe32a14318d0daebad7319ba4143a25fc02be4
Author: Thomas Groh <[email protected]>
Date: 2017-03-15T22:28:47Z
Revert "[BEAM-1092] Replace hyphens in artifactId with dots in shading
relocations"
This reverts commit 2b55e0798f44e3fa644e7df1eaab43898ecf9c46.
commit 12873b9500c31b78d84ec6d52c0d9cf1a68edc39
Author: Thomas Groh <[email protected]>
Date: 2017-03-15T22:28:49Z
Revert "[BEAM-1092] Shade commonly used libraries (e.g. Guava) to avoid
class conflicts"
This reverts commit 03d78097ba0a2d55a9e8dcbaf11e0f8182f223c1.
----
> Shade commonly used libraries (e.g. Guava) to avoid class conflicts
> -------------------------------------------------------------------
>
> Key: BEAM-1092
> URL: https://issues.apache.org/jira/browse/BEAM-1092
> Project: Beam
> Issue Type: Bug
> Components: examples-java, sdk-java-extensions
> Affects Versions: 0.3.0-incubating
> Reporter: Maximilian Michels
> Assignee: Frances Perry
>
> Beam shades away some of its dependencies like Guava to avoid user classes
> from clashing with these dependencies. Some of the artifacts, e.g. KafkaIO,
> do not shade any classes and directly depend on potentially conflicting
> libraries (e.g. Guava). Also, users might manually add such libraries as
> dependencies.
> Runners who add classes to the classpath (e.g. Hadoop) can run into conflict
> with multiple versions of the same class. To prevent that, we should adjust
> the Maven archetypes pom files used for the Quickstart to perform shading of
> commonly used libraries (again, Guava is often the culprit).
> To prevent the problem in the first place, we should expand the shading of
> Guava and other libraries to all modules which make use of these.
> To solve both dimensions of the issue, we need to address:
> 1. Adding shading of commonly used libraries to the archetypes poms
> 2. Properly shade all commonly used libraries in the SDK modules
> 2) seems to be of highest priority since it affects users who simply use the
> provided IO modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
