[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Publish vendored dependencies independently

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 <lcwik@xxxxxxxxxx> 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:

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.

On Thu, Oct 25, 2018 at 10:59 AM Lukasz Cwik <lcwik@xxxxxxxxxx> 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 <mxm@xxxxxxxxxx> wrote:
On 25.10.18 19:23, Lukasz Cwik wrote:
> On Thu, Oct 25, 2018 at 9:59 AM Maximilian Michels <mxm@xxxxxxxxxx
> <mailto:mxm@xxxxxxxxxx>> 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!