git.net

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

Re: (fyi) PR#7324 updates how projects consume vendored guava


Hi Scott,

Can testing of the artifact prior to release not be done against the staging repo?


It is unfortunate that we have to change the imports on every patch. Is it not sufficient to just update the artifact version?

Thomas



On Wed, Dec 19, 2018 at 1:49 PM Scott Wegner <scott@xxxxxxxxxx> wrote:
Just a heads up: PR#7324 [1] just got merged which fixes an issue with our vendored guava artifact and JNI: see BEAM-6056 [2] for details. Important changes for you:

a. IntelliJ doesn't understand how our vendored guava is built and will give red squigglies. This is annoying but temporary while we release a new vendored artifact.
b. The guava vendoring prefix has changed. If you have work-in-progress, you'll hit this when you merge into master. Update any new guava imports to: org.apache.beam.vendor.grpc.v1p3p1.[..]

Read on for details..

The fix for BEAM-6056 included two changes:
1. Updated package prefix for vendored guava symbols: o.a.b.vendor.grpc.v1_13_1 -> o.a.b.vendor.grpc.v1p3p1
2. Move project dependencies to consume vendored guava from :beam-vendor-grpc-1_13_1 project rather than the published Maven artifact.

Consuming from the integrated project artifact (#2) was necessary in order to make the changes and validate them inline without needing to first publish a Maven release. However, this has some downsides: notably, IntelliJ struggles to understand shaded dependencies [3]. I believe we should move back to consuming pre-published vendor artifacts. The first step is to publish a new vendored beam-vendor-grpc-1_13_1 artifact; I can start that process.



Got feedback? 
tinyurl.com/swegner-feedback