Repository navigation
Does google-cloud-contrib belong in the google-cloud-java BOM? #3680
Description
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-contrib</artifactId>
<version>0.62.1-alpha-SNAPSHOT</version><!-- {x-version-update:google-cloud-contrib:current} -->
</dependency>
- This is itself a BOM (type pom) and has no jar.
- Presumably it's contributed code? What's actually in here? Is this something we support?
- This is pre-release alpha code.
- If this should be included, I think it still needs to have its type set to pom for this to work.
Activity
lbergelson commentedon Sep 25, 2018
google-cloud-contribincludesgoogle-cloud-niowhich is a filesystem provider which allowsgs://paths to be accessed by standard javaFilesoperations. A set ofgoogle-cloud-niojars are published to maven central as part of thegoogle-cloud-javastandard release.My understanding is that this code is supported by google and will continue to be supported.
I just want to be sure that this doesn't get dropped from the project or something like that since it's essential for interoperation between our software and the google cloud.
Tagging @jean-philippe-martin since he's our main contact person.
jean-philippe-martin commentedon Sep 25, 2018
google-cloud-nio very much works, is supported, and has users. It's true that it's still marked as alpha but that's mostly our fault for not updating that notice; I don't think this is an accurate representation of its current reliability anymore.
google-cloud-nio is hierarchically under google-cloud-contrib and thus (AFAIK) requires it to be there. I feel pretty strongly that it should still be included.
elharo commentedon Sep 26, 2018
This issue is only about whether the contrib libraries belong in the google-cloud-bom. It's not suggesting removing them from the repo or deleting them.
This is a good case study for JLBP-8: Advance widely used functionality to a stable version
https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-8.md
If google-cloud-nio should be used and is supported and committed to, it shouldn't be marked alpha. In the past, IMHO, we've been too cautious about moving versions to 1.0. We need to finish what we start.
Conway's law also applies. It's not obvious to me that google-cloud-nio belongs in this repo, though it belongs somewhere. Others more familiar with this particular package may correct me, but it seems somewhat out of place here and orthogonal to the other parts of google-cloud-java. I wouldn't be at all surprised if google-cloud-nio ended up here because some developer had commit rights and it was easier to start an experiment here than to set up a new project and a new repo. @garrettjonesgoogle We should consider writing a JLPB that lays out some rules for when it's appropriate to create a new repo.
jean-philippe-martin commentedon Sep 26, 2018
@elharo, you don't need to speculate about the origin of google-cloud-nio, you are talking to one of the two original contributors, @jart being the other. We put NIO in gcloud-java because gcloud-java's mission is to make Google Cloud easier to use from Java, and google-cloud-nio does exactly this.
jart commentedon May 3, 2019
For what it's worth, I'm still supportive of moving NIO into a first-class folder, or it's own repo. A lot of top-notch engineering went into that. If it's marked alpha, please take into consideration my standards for alpha are sort of up there with GMail's definition of beta :)
codyoss commentedon Dec 4, 2019
@elharo are you still debating removing
google-cloud-contrib?elharo commentedon Dec 4, 2019
It's worth having a discussion and making some decisions once and for all. Especially with repo splitting we're doing, I think it makes more sense than ever to move it to its own repo.
And if we are supporting this, in its own repo or here, we need to commit to the API and get it out of alpha.
jean-philippe-martin commentedon Dec 4, 2019
I've said this before, but for the record I think that having NIO as part of the google-cloud-java repo is the best choice because it makes it easily discoverable. In addition, having everything together means we have the tests to ensure a change in one won't break the other.
chingor13 commentedon Dec 4, 2019
I think that the artifacts contained under contrib (storage nio, spanner jdbc driver, etc) should be contained in the google-cloud-bom, but not the google-cloud-contrib artifact (which is a parent pom for the higher level client library integrations).
jart commentedon Dec 5, 2019
Another one of the authors of NIO here. I'm fine with a different repo, but agree with @jean-philippe-martin that discoverability is important. NIO offers value since it puts GCS at a customer's fingertips, instantly, via the canonical Java filesystem APIs.
If the repo is moved, then could google-cloud-java continue to show its support by including NIO in its install binaries? That way you guys aren't burdened with NIO-related triaging/review/refactor maintenance toil, but continue to preserve the same level of functionality for your users.
chingor13 commentedon Jan 7, 2020
We've removed
google-cloud-contribfrom thegoogle-cloud-bom, butgoogle-cloud-nio,google-cloud-notificationandgoogle-cloud-spanner-jdbcare all included directly in the bom.deps: update dependency com.google.api.grpc:proto-google-cloud-bigque…
chore: Update README and CI with the new name of showcase module. (#3680