Codecov Report

Merging #278 (8acd358) into master (825f186) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #278   +/-   ##
=========================================
  Coverage     71.40%   71.40%           
  Complexity     1104     1104           
=========================================
  Files            24       24           
  Lines          3396     3396           
  Branches        525      525           
=========================================
  Hits           2425     2425           
  Misses          756      756           
  Partials        215      215           

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 825f186...8acd358. Read the comment docs.

I don't think this is correct. If they're not needed by this project's compile classpath, they should be added in the downstream project; not here.

@elharo
Hmmm... That is true. It should however be a compile time dependency that should be included automatically as a transitive dependency from google-cloud-spanner. So I agree, adding it here is not the real solution.

It seems that there are a couple of problems here:

1. The reason that the grpc-google-cloud-spanner-admin-... dependencies were not considered transitive, was that they were added explicitly as test dependencies. Removing those as test dependencies is enough to solve this specific problem.
2. All other compile time dependencies currently declared in the JDBC pom can now also be removed, except for the dependency on google-cloud-spanner.
3. The JDBC pom imports a specific version of google-cloud-spanner-bom, which determines the version of the Spanner client library to use. That version will be used if the application only adds a specific version of google-cloud-spanner-jdbc as a dependency. That seems good to me.
4. An application that imports the libraries-bom and adds google-cloud-spanner-jdbc as a dependency will get the versions of google-cloud-spanner and google-cloud-spanner-jdbc that are defined in libraries-bom. The version of google-cloud-spanner in libraries-bom can be different from the one defined in google-cloud-spanner-jdbc. This is currently also the case, as google-cloud-spanner-jdbc imports version 2.0.2, while the libraries-bom specifies version 3.0.4. The latter version will be added as a compile time dependency for an application that defines google-cloud-spanner-jdbc as a dependency. That could be a problem.

@suztomo Any ideas what the best approach would be for the last point?

I agree with Elliotte's point. If some artifacts are missing proper dependencies, we should fix that there.

Let me dig your finding further. GoogleCloudPlatform/java-docs-samples#4278 (comment)

I agree with Elliotte's point. If some artifacts are missing proper dependencies, we should fix that there.

Yes, I agree with that. But in this case it should be a transitive dependency, but seems to have lost that status. And that seems to be caused by the fact that it was added as a test dependency in the pom of this project, while it was already a compile-time dependency. I have not been able to find a satisfactory explanation as to why the dependency was still transitive in earlier versions of the JDBC driver, but not anymore.