google-api-java-client-services
google-api-java-client-services copied to clipboard
Create a BOM for google-api-java-client-services
google-api-java-client-services needs a BOM, as per https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-15.md .
It looks like the best way to handle a BOM in this repo is to generate it, probably using templating in some fashion.
Can this simply be added to the google-api-java-client BOM?
https://github.com/chingor13/google-api-java-client/blob/47c51549cc3b5e2890908ebcb5c62ec733f1ed7d/google-api-client-bom/pom.xml
These versions will change at a much different cadence (daily) than the google-api-client-bom artifact so I'm not sure that's feasible.
Also, how important is this one as each of the service artifacts are independent from each other and reference the same dependencies?
@chingor13 they only reference the same dependencies if all of the service artifacts you use are built against the same shared library version, but there seem to be 3-4 shared library variants built actively at any point in time. You could easily accidentally pull in google storage for 1.23.0 and google bigquery for 1.26.0; the BOM enables users to guarantee they get 1.26.0 for everything.
Ok, that makes sense.
We can also separate the cadence of releasing the bom from the artifacts. We likely don't need to publish it every day (even though individual artifacts may change). Weekly should be good enough.
Yep, weekly is probably fine for BOM release cadence.
This is actually blocked on #447 as we can only pick a single version of an API with the current versioning scheme. For example, we cannot include both google-api-services-cloudresourcemanager's v1 and v2 versions in the bom. We cannot just arbitrarily pick a version as a user may need v1.
Just using maven for dependencies is not clear. let's take calendar API - https://mvnrepository.com/artifact/com.google.apis/google-api-services-calendar. Both name and last version is confusing. Because in name is stated that recent version is using API client with version 1.25. It is aligned with recent visible version v3-rev411-1.25.0. But it was a surprise that at positions > 1000 - below year 2015 - there are actually versions from this year with support of client 2.0. It's very confusing.