-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: checking the behavioral compatibility in the libraries in the LTS BOM #1974
Comments
Start with a shell script to
For unit tests. Think about Integration tests later. For pom.xml, fill version element from the value in the LTS BOM. |
I picked java-spanner's v4.0.1 tag as the starter and I ran the same command as .github/workflow/ci.yaml (without modifying any code) and the build fails on my cloudtop. Why?
It works with v5.0.0 tag. |
While writing code for it (https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/lts_tests), I found that java-spanner project (google-cloud-spanner) does not compile with Guava 30.1-jre (It builds with 30.1-android). In both my MacBook and Cloudtop (Linux). https://gist.github.com/suztomo/bfb4765ad9e32a59f0d8d786f1092232
These classes are simple interface from Guava.
Why doesn't the Java compiler choose to use Guava's Example PR that shows the strange compilation failure: googleapis/java-spanner#959 |
I think the compiler plugin's source/target 1.7 is causing the compilation failure: in the google-cloud-shared-config:
If that's the case, then we cannot build the Yoshi repositories with Guava JRE flavor. |
The Maven surefire plugin has configuration to set runtime class path (document). For each library, I need to supply 2 things in surefire configuration (
For example, when I want to run the java-spanner test with very old Guava version, I supply the configuration:
It worked as expected:
|
google-http-java-client/google-http-client-appengine failed:
Does this mean the google-http-client-appengine v1.39.1 does not work with appengine-api-1.0-sdk 1.9.86? The google-http-client-appengine master uses 1.9.71. But the master branch of google-http-client-appengine with 1.9.86 just works fine. Maybe there's problem in supplying newer version in the test class path? This causes problem;
I don't see
The old version 1.9.71 defines it as final.
How come |
The test in google-auth-library-java's appengine module doesn't run. Skipping it for now.
|
java-bigtable-hbase fails with https://gist.github.com/suztomo/7c3a50d3ab03f0ee62ec00f3ded3d262 The test runs fine if there's no test-runtime dependency override. com.google.apis:google-api-services-bigquery:v2-rev20200719-1.30.10 has the class. |
Google Map Services needed to have
|
It might be a good idea to file bugs in the respective repos for individual failures you're uncovering. We should fix these at head ASAP to have a chance of getting them into the June release. |
Yes, I'll do. |
The build that worked fine at the time of the release of a library might not work later due to unstable (or retired) repositories. google-http-java-client repository at git tag
|
Problem
We'd like to see the libraries in LTS BOM are compatible with each other. This is not just for Java class file signature but also for behavioral change.
Idea: run the tests with LTS BOM
To capture behavioral change, we can leverage the tests in the repository of the each library in LTS BOM.
For example, if I want to check the compatibility of protobuf-java in LTS BOM and grpc-protobuf, then I can modify build.gradle to include
api enforcedPlatform('com.google.cloud:gcp-lts-bom:0.1.0-SNAPSHOT')
to see the compatibility.I checkout grpc-java Git repository and insert the
enforcedPlatform
to one of build.gradle:If the tests pass, then the LTS BOM is compatible with the grpc-protobuf.
Implementation Design
Repositories
Checkout the following repositories with a release tag.
Checking out a specific revision
For example, to checkout java-spannner repository with a specific release tag, run the following command:
For Gradle project
For the target modules, insert the BOM after keyword "dependencies":
so that it would look like:
For Maven project
The text was updated successfully, but these errors were encountered: