Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion hadoop-project/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@
<findbugs.version>3.0.5</findbugs.version>
<dnsjava.version>3.6.1</dnsjava.version>

<guava.version>33.1.0-jre</guava.version>
<guava.version>27.0-jre</guava.version>
<guice.version>5.1.0</guice.version>

<bouncycastle.version>1.78.1</bouncycastle.version>
Expand Down
10 changes: 10 additions & 0 deletions hadoop-tools/hadoop-gcp/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -427,6 +427,11 @@

<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.1.0-jre</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the https://github.com/google/guava/blob/v33.4.8/README.md says:

  1. APIs without @Beta will remain binary-compatible for the indefinite
    future. (Previously, we sometimes removed such APIs after a deprecation
    period. The last release to remove non-@Beta APIs was Guava 21.0.) Even
    @Deprecated APIs will remain (again, unless they are @Beta). We have no
    plans to start removing things again, but officially, we're leaving our
    options open in case of surprises (like, say, a serious security problem).

So Guava seems to ensure backward compatibility since 22, except for @Beta API? Suppose the GCS client does not use @Beta API, it is seems to be safe and simple to always use the latest Guava in the whole Hadoop project?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, maybe it's safe to do the upgrade then.

I propose that we move ahead with this PR on the feature branch, using a targeted approach just for the hadoop-gcp module. The decision to upgrade for the whole project is a separate discussion and deserves to be tracked in a dedicated bug/PR/release note.

@arunkumarchacko is helping with a little more testing before I commit this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The decision to upgrade for the whole project is a separate discussion and deserves to be tracked in a dedicated bug/PR/release note.

make sense

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to @arunkumarchacko for additional testing to confirm that this works!

</dependency>
<dependency>
<!--
We're using a specific Protobuf version to ensure compatibility with the
Expand Down Expand Up @@ -457,6 +462,11 @@
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
</exclusion>
<!-- Exclude guava 27.0-jre -->
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</exclusion>
<!-- Exclude protobuf-java 2.5.0 -->
<exclusion>
<groupId>com.google.protobuf</groupId>
Expand Down