[gax-java] fix: make GaxProperties.version accessible in Android by miraleung · Pull Request #1117 · googleapis/gax-java

miraleung · 2020-06-04T20:01:37Z

No description provided.

miraleung · 2020-06-04T20:02:20Z

I tested this in an Android app and standalone Java binary, and they both work.

codecov · 2020-06-04T20:04:16Z

Codecov Report

Merging #1117 into master will increase coverage by 0.00%.
The diff coverage is 20.00%.

@@            Coverage Diff            @@
##             master    #1117   +/-   ##
=========================================
  Coverage     78.65%   78.66%           
+ Complexity     1170     1169    -1     
=========================================
  Files           204      204           
  Lines          5187     5189    +2     
  Branches        416      417    +1     
=========================================
+ Hits           4080     4082    +2     
- Misses          932      933    +1     
+ Partials        175      174    -1

Impacted Files	Coverage Δ	Complexity Δ
...in/java/com/google/api/gax/core/GaxProperties.java	`55.00% <20.00%> (+5.00%)`	`5.00 <1.00> (-1.00)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf1bce8...374f4f5. Read the comment docs.

elharo · 2020-06-04T20:10:51Z

+    // Always read GaxProperties' version from the properties file.
+    if (!libraryClass.equals(GaxProperties.class)) {
+      version = getLibraryVersion(libraryClass);
+      if (!DEFAULT_VERSION.equals(version)) {


why the if? seems we can return unconditionally here if it is the default version. Or do you want to read from gradle.properties instead if this is the default version?

Since this seems applicable to any generic library class (i.e. keep reading if the version is empty, aka DEFAULT_VERSION), I was trying to keep the non-GaxProperties logic the same.

vam-google · 2020-06-05T04:50:53Z

+      }
    }

-    try (InputStream in = libraryClass.getResourceAsStream("/dependencies.properties")) {


Why is this needed? Most probably this will break execution as a bazel artifact (i.e. when a client library is build with bazel and executed from bazel context). In any case, introducing another properties file will duplicate version information in two places. Plus, the version in dependencies.properties is automatically bumped by Yoshi's tools during releases.

This is similar to this PR in google-http-java-client. Note that dependencies.properties was never being pulled into the Android JAR. This file is also suboptimal to include since it includes every dependency, which we don't necessarily want gax-external developers to parse.

On the other hand, gradle.properties is a standard artifact that is expected to be provided in many libraries and works on both Android and plain Java binaries.

tl;dr; Please strongly consider just making dependencies.properties work in android env.

google-http-java-client is not used via bazel, that is why it does not matter for it. Also it does not have dependencies.properites.

Note, dependencies.properties is used in any scenario (with or without bazel). It is the source of truth for the version.

As for gradle.properties, it makes gax-java as java artifact depend on its build system (gradle, which is one of many) during runtime. The same artifact can be built by maven, for example, which makes gradle.properties an alien thing there. I guess it is also not even included in bazel artfiact unlike dependencies.properties (https://github.com/googleapis/gax-java/blob/master/gax/BUILD.bazel#L43). If you run bazel test //... for gax-java, does it work (most probably it will not)?

In any case, most importantly, this value is not updated automatically so after the next release it will start reporting wrong version number. There is TODO, but it is not sufficient (after all this PR fixes one relatively small issue, so introducing a future issue with it is not "cost efficient").

IMO we shouldn't include all of dependencies.properties, so here's a workaround. I'm now generating a new dependencies.properties that pulls in version.gax at build time. This still works with bazel test //..., ./gradlew test, Android, and plain Java binaries.

We also did not have a GaxPropertiesTest before, so I've added one.

elharo

Please merge to master

miraleung · 2020-06-05T21:43:15Z

Merged to master.

vam-google · 2020-06-05T22:35:22Z

 }
+
+task generateProjectProperties {
+    ext.outputFile = file("gax/src/main/resources/dependencies.propertoes")


propertoes -> properties

vam-google · 2020-06-05T22:36:42Z

+      }
    }

    try (InputStream in = libraryClass.getResourceAsStream("/dependencies.properties")) {


This reads dependencies.properteis, but generateProjectProperties writes to the file with typo dependencies.propertoes. Looks like the file (even if it did not contain a typo) is never read (and the tests pass without the need to copy the file).

vam-google · 2020-06-05T22:42:33Z

@@ -0,0 +1 @@
+version.gax=1.56.0


Please add newline char.
Please justify the need of copying the file. What harm does including the whole file makes?
Even if we do the copy, shouldn't it be created only as build artifacts but not included in git (otherwise it is an unnecessary duplication, and confusing source artifacts created during build)?

Removed from git.

vam-google · 2020-06-05T22:49:45Z

  // ----------

  task sourcesJar(type: Jar, dependsOn: classes) {
+    dependsOn generateProjectProperties


Where is the generated file included - in -sources jar or in .class files jar? If it is in sources jar only, then it will not be accessible as a resource during runtime.

.class files, because it's accessible when running tests or an Android APK.

vam-google

LGTM, please use your judgement

miraleung · 2020-06-06T00:10:47Z

Found a way to keep the generated files only in the build directory.

miraleung · 2020-06-06T00:25:28Z

The optimal solution was to generate and write a subset of dependencies.properties to a build-only directory, and that worked on Android, gradle / bazel tests, and plain Java binaries when built locally. However, this fails on CI and TravisCI, so we'll have to go back to the second-last commit. The CI failures are a likely motivator for the http-client workaround.

fix: make GaxProperties.version accessible in Android

c12779a

googlebot added the cla: yes This human has signed the Contributor License Agreement. label Jun 4, 2020

miraleung linked an issue Jun 4, 2020 that may be closed by this pull request

GaxProperties.getLIbraryVersion probably doesn't work on Android #822

Closed

miraleung requested a review from elharo June 4, 2020 20:01

miraleung requested a review from vam-google June 4, 2020 20:03

elharo reviewed Jun 4, 2020

View reviewed changes

vam-google reviewed Jun 5, 2020

View reviewed changes

elharo reviewed Jun 5, 2020

View reviewed changes

miraleung and others added 2 commits June 5, 2020 21:39

fix: add GaxPropertiesTest, generate dependencies.properties

1305707

Merge branch 'master' into fixit/version

15565c6

vam-google reviewed Jun 5, 2020

View reviewed changes

fix: typos, remove untracked files

ca91181

vam-google approved these changes Jun 5, 2020

View reviewed changes

fix: move generated properties to a buildDir

7fd9779

fix: revert back to second-best approach to fix CI builds

374f4f5

miraleung merged commit ecbab4a into master Jun 6, 2020

miraleung deleted the fixit/version branch June 6, 2020 00:32

chingor13 mentioned this pull request Jun 10, 2020

Release gax-java v1.57.0 #1127

Merged

Conversation

miraleung commented Jun 4, 2020

Uh oh!

miraleung commented Jun 4, 2020

Uh oh!

codecov Bot commented Jun 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vam-google Jun 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elharo left a comment

Choose a reason for hiding this comment

Uh oh!

miraleung commented Jun 5, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vam-google left a comment

Choose a reason for hiding this comment

Uh oh!

miraleung commented Jun 6, 2020

Uh oh!

miraleung commented Jun 6, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov Bot commented Jun 4, 2020 •

edited

Loading

vam-google Jun 5, 2020 •

edited

Loading