google-api-java-client-services icon indicating copy to clipboard operation
google-api-java-client-services copied to clipboard

Create a BOM for google-api-java-client-services

Open garrettjonesgoogle opened this issue 7 years ago • 7 comments
trafficstars

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.

garrettjonesgoogle avatar Nov 02 '18 21:11 garrettjonesgoogle

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

elharo avatar Nov 09 '18 18:11 elharo

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 avatar Nov 09 '18 18:11 chingor13

@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.

garrettjonesgoogle avatar Nov 09 '18 18:11 garrettjonesgoogle

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.

chingor13 avatar Nov 09 '18 18:11 chingor13

Yep, weekly is probably fine for BOM release cadence.

garrettjonesgoogle avatar Nov 09 '18 18:11 garrettjonesgoogle

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.

chingor13 avatar Dec 17 '18 22:12 chingor13

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.

mykolap avatar Oct 05 '23 15:10 mykolap