I have made some incremental progress on this and wanted to release our first vendored dependency of gRPC 1.13.1 since I was able to fix a good number of the import/code completion errors that Intellij was experiencing. I have published an example of what the jar/pom looks like in the Apache Staging repo: https://repository.apache.org/content/groups/snapshots/org/apache/beam/beam-vendor-grpc-1_13_1/
You can also checkout[1] and from a clean workspace run: ./gradlew :beam-vendor-grpc-1_13_1:publishToMavenLocal -PisRelease -PvendoredDependenciesOnly which will build a vendored version of gRPC that is published to your local maven repository. All the projects that depended on the gradle beam-vendor-grpc-1_13_1 project are now pointing at the Maven artifact org.apache.beam:beam-vendor-grpc-1_13_1:0.1 I was planning to follow the Apache Beam release process but only for this specific artifact and start a vote thread if there aren't any concerns. 1: https://github.com/lukecwik/incubator-beam/commit/4b1b7b40ef316559f81c42dfdd44da988db201e9 On Thu, Oct 25, 2018 at 10:59 AM Lukasz Cwik <lc...@google.com> wrote: > Thats a good point Thomas, hadn't considered the lib/ case. I also am > recommending what Thomas is suggesting as well. > > On Thu, Oct 25, 2018 at 10:52 AM Maximilian Michels <m...@apache.org> > wrote: > >> On 25.10.18 19:23, Lukasz Cwik wrote: >> > >> > >> > On Thu, Oct 25, 2018 at 9:59 AM Maximilian Michels <m...@apache.org >> > <mailto:m...@apache.org>> wrote: >> > >> > Question: How would a user end up with the same shaded dependency >> > twice? >> > The shaded dependencies are transitive dependencies of Beam and >> thus, >> > this shouldn't happen. Is this a safe-guard when running different >> > versions of Beam in the same JVM? >> > >> > >> > What I was referring to was that they aren't exactly the same >> dependency >> > but slightly different versions of the same dependency. Since we are >> > planning to vendor each dependency and its transitive dependencies as >> > part of the same jar, we can have vendor-A that contains shaded >> > transitive-C 1.0 and vendor-B that contains transitive-C 2.0 both with >> > different package prefixes. It can be that transitive-C 1.0 and >> > transitive-C 2.0 can't be on the same classpath because they can't be >> > perfectly shaded due to JNI, java reflection, magical property >> > files/strings, ... >> > >> >> Ah yes. Get it. Thanks! >> >
