[
https://issues.apache.org/jira/browse/BEAM-8747?focusedWorklogId=347590&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-347590
]
ASF GitHub Bot logged work on BEAM-8747:
----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Nov/19 18:28
Start Date: 21/Nov/19 18:28
Worklog Time Spent: 10m
Work Description: kennknowles commented on pull request #10172:
[BEAM-8747] Guava dependency cleanup
URL: https://github.com/apache/beam/pull/10172#discussion_r349243507
##########
File path: sdks/java/io/kinesis/build.gradle
##########
@@ -34,6 +34,7 @@ dependencies {
compile library.java.slf4j_api
compile library.java.joda_time
compile library.java.jackson_dataformat_cbor
+ compile library.java.guava
Review comment:
@aromanenko-dev the point is that this library has already been pinned to
20.0 for a long time, I think because `BeamModulePlugin` is going in and
overriding things even when it doesn't have to. So we know it currently is
working and @suztomo is just recording the status quo.
By the way it isn't so simple as KPL depending on 18.0. This IO module also
links against the Kinesis client which depends on 26.0-jre and it has been
pinned downward to 20.0. So there's not one version of Guava that these AWS
libs use.
Here's the excerpt from the linked dep tree, which is already how it has
been for some time.
```
compile - Dependencies for source set 'main' (deprecated, use
'implementation' instead).
+--- com.amazonaws:amazon-kinesis-client:1.13.0
| +--- com.google.guava:guava:26.0-jre -> 20.0
+--- com.amazonaws:amazon-kinesis-producer:0.13.1
| +--- com.google.guava:guava:18.0 -> 20.0
```
Highest priority is choosing a version of Guava that works for this
connector. So it is OK for it to diverge and use its own version. The aliases
at `library.java.*` exist just to help Beam modules cooperate. We probably want
to keep moving `library.java.guava` forward, for example I think we need an
upgrade support Java 11. If that breaks this module, then we will just have to
fork the version.
Is there enough test coverage to catch any problems? Is the Kinesis client
library open source so you can clone it and see if it compiles with a new
version? That could be a way to check full API compatibility that might be
missed by testing.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 347590)
Time Spent: 1h 50m (was: 1h 40m)
> Remove Unused non-vendored Guava compile dependencies
> -----------------------------------------------------
>
> Key: BEAM-8747
> URL: https://issues.apache.org/jira/browse/BEAM-8747
> Project: Beam
> Issue Type: Bug
> Components: build-system
> Reporter: Tomo Suzuki
> Assignee: Tomo Suzuki
> Priority: Major
> Attachments: Guava used as fully-qualified class name.png
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> [~kenn] says:
> BeamModulePlugin just contains lists of versions to ease coordination across
> Beam modules, but mostly does not create dependencies. Most of Beam's modules
> only depend on a few things there. For example Guava is not a core
> dependency, but here is where it is actually depended upon:
> $ find . -name build.gradle | xargs grep library.java.guava
> ./sdks/java/core/build.gradle: shadowTest library.java.guava_testlib
> ./sdks/java/extensions/sql/jdbc/build.gradle: compile library.java.guava
> ./sdks/java/io/google-cloud-platform/build.gradle: compile library.java.guava
> ./sdks/java/io/kinesis/build.gradle: testCompile library.java.guava_testlib
> These results appear to be misleading. Grepping for 'import
> com.google.common', I see this as the actual state of things:
> - GCP connector does not appear to actually depend on Guava in compile scope
> - The Beam SQL JDBC driver does not appear to actually depend on Guava in
> compile scope
> - The Dataflow Java worker does depend on Guava at compile scope but has
> incorrect dependencies (and it probably shouldn't)
> - KinesisIO does depend on Guava at compile scope but has incorrect
> dependencies (Kinesis libs have Guava on API surface so it is OK here, but
> should be correctly declared)
> - ZetaSQL translator does depend on Guava at compile scope but has incorrect
> dependencies (ZetaSQL has it on API surface so it is OK here, but should be
> correctly declared)
> We used to have an analysis that prevented this class of error.
> Once the errors are fixed, the guava_version is simply a version that we have
> discovered that seems to work for both Kinesis and ZetaSQL, libraries we do
> not control. Kinesis producer is built against 18.0. Kinesis client against
> 26.0-jre. ZetaSQL against 26.0-android.
> (or maybe I messed up in my analysis)
> Kenn
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
