Note, I could also release the vendored version of guava 20 in preparation for us to start consuming it. Any concerns?
On Tue, Nov 13, 2018 at 3:59 PM Lukasz Cwik <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> On 25.10.18 19:23, Lukasz Cwik wrote: >>> > >>> > >>> > On Thu, Oct 25, 2018 at 9:59 AM Maximilian Michels <[email protected] >>> > <mailto:[email protected]>> 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! >>> >>
