Google-cloud-java: Does google-cloud-contrib belong in the google-cloud-java BOM?

[elharo]

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

1. This is itself a BOM (type pom) and has no jar.
2. Presumably it's contributed code? What's actually in here? Is this something we support?
3. This is pre-release alpha code.
4. If this should be included, I think it still needs to have its type set to pom for this to work.

[lbergelson]

google-cloud-contrib includes google-cloud-nio which is a filesystem provider which allows gs:// paths to be accessed by standard java Files operations. A set of google-cloud-nio jars are published to maven central as part of the google-cloud-java standard 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]

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]

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]

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

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]

@elharo are you still debating removing google-cloud-contrib?

[elharo]

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]

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]

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]

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]

We've removed google-cloud-contrib from the google-cloud-bom, but google-cloud-nio, google-cloud-notification and google-cloud-spanner-jdbc are all included directly in the bom.