Ditch mavenLocal

[jamesward]

Currently grpc-kotlin's CI publishes to the Maven Local repo, then the samples use that repo to verify that everything works. But it turns out that using mavenLocal() has a bunch of bad side effects. For example, if a dependency is pulled into Maven Local via Maven, then it doesn't have the Gradle metadata and that can cause differing dependency resolution. So this project should ditch Maven Local to support more deterministic builds.

[bubenheimer]

Will I still be able to do 'publishToMavenLocal' myself, though? That's an easy standard Gradle thing an outside contributor can use to build and use artifacts locally for testing PRs, etc. I just tried to build a major Android-related project that somehow disabled 'publishToMavenLocal', and at some point I just had to give up, it was a big waste of time and certainly did not increase my appreciation levels for said project.

[jamesward]

This shouldn't impact you. We just won't use mavenLocal() in the examples project. Curious for more details on why you are using publishToMavenLocal though.

[bubenheimer]

Generally speaking I like using publishToMavenLocal when I want to test a PR or other change to a 3rd party project. That way I can easily try out the changed artifacts in my own projects locally to see if the change works as I expected.

Is there a better way? Straightforward alternatives I can think of: running my own proper repo locally (too much maintenance), copying build artifacts over to my project (dependencies are lost), publishing to public repo with changed coordinates (have to change some stuff around in 3rd party project and my own), maybe build via GitHub (no experience there). The other project I mentioned recommended using direct project() dependencies, but that requires my project's build setup to be compatible with theirs.

[jamesward]

I'm currently exploring using Gradle Composite builds as a way to handle this scenario:
https://docs.gradle.org/current/userguide/composite_builds.html

But I haven't yet tested this approach with grpc-kotlin.