Skip to content
This repository has been archived by the owner on Sep 26, 2023. It is now read-only.

gax-java should put its dependencies on the compile classpath, not just the runtime classpath #1540

Closed
nwbirnie opened this issue Oct 19, 2021 · 8 comments
Labels
type: question Request for information or clarification. Not an issue.

Comments

@nwbirnie
Copy link

A recent change removed most of the transitive dependencies from the compile time classpath in maven.

This means that downstream projects need to re-declare all the dependencies and keep these in sync with what GAX requires. This creates the risk that overtime our dependency sets diverge, leading to subtle bugs. As a downstream project I just want to bump the GAX version as required by the GAPIC generators and have that include all the transitive dependencies for me.

Before this change this was working. We used to depend on com.google.api:gax-java and that would pull in the the correct version of gRPC, protobuf etc. as needed by the generated code, and GAX itself.

Now to get this to compile I need to copy the GAX dependencies to my project and make sure these are kept in sync.

Can we revert this change?

@nwbirnie nwbirnie added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Oct 19, 2021
@suztomo
Copy link
Member

suztomo commented Oct 19, 2021

(GAX 2.6.0 declared every dependency as runtime scope. This was unexpected result from Gradle version upgrade.)

That change #1535 is moving the "runtime" scope to "compile" scope for the classes in the API surface of GAX. It was released as 2.6.1.

Screen Shot 2021-10-19 at 3 14 41 PM

In general,

  • For the libraries you use for GAX's API surface, the change made the dependencies as compile scope.
  • For the libraries you use without GAX, you declare the dependencies.

This follows Gradle's "API and implementation separation".

In Google Cloud Java client libraries, we also use the compatible versions GAX, gRPC, protobuf, defined in https://github.com/googleapis/java-shared-dependencies.

I might be missing the specific problem you're facing. Would you give me the URL of the project?

@chanseokoh chanseokoh added type: question Request for information or clarification. Not an issue. and removed type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p2 Moderately-important priority. Fix may not be included in next release. labels Oct 19, 2021
@nwbirnie
Copy link
Author

Oh cool, I wasn't aware of https://github.com/googleapis/java-shared-dependencies. This solves my problem, ty!

https://github.com/googleads/google-ads-java/ is our project if you're curious.

@suztomo
Copy link
Member

suztomo commented Oct 19, 2021

(Sorry for confusion I thought you're part of googleapis organization.) https://github.com/googleapis/java-shared-dependencies is not intended to be used outside googleapis organization (at least for now).

Doesn't GAX 2.6.1, which declares the API surface, resolve your problem?

@suztomo suztomo reopened this Oct 19, 2021
@suztomo
Copy link
Member

suztomo commented Oct 19, 2021

@nwbirnie If you still need a BOM, how about using the Libraries BOM? This includes GAX, gRPC, protobuf, etc. and intended to be used by outside Google Cloud organization (targeted for Cloud customers).

https://github.com/GoogleCloudPlatform/cloud-opensource-java/wiki/The-Google-Cloud-Platform-Libraries-BOM

@nwbirnie
Copy link
Author

Well maybe googleapis is actually suitable, since we publish our protos there and use the same GAPIC generators as everyone else? WDYT?

@suztomo
Copy link
Member

suztomo commented Oct 20, 2021

@Neenu1995 You own this shared dependencies BOM. What do you think about https://github.com/googleads/google-ads-java/ using the shared dependencies BOM?

@Neenu1995
Copy link
Contributor

Neenu1995 commented Oct 20, 2021

As long as we do not have to add more dependencies to shared-dependencies you are welcome to use it. It is purely for version management and have a biweekly release cadence.
Refer this doc for more information on how we implement dependency management.

@chanseokoh
Copy link
Contributor

Not an issue. Closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: question Request for information or clarification. Not an issue.
Projects
None yet
Development

No branches or pull requests

4 participants