A vendored Guava 20.0 and gRPC 1.13.1 have been published. PR 7105[1] will enable consuming the first one which should help many Intellij/Eclipse contributors with import issues.
https://github.com/apache/beam/pull/7105 On Thu, Nov 15, 2018 at 6:06 PM Lukasz Cwik <[email protected]> wrote: > I have created the artifacts and sent out a vote thread. > > On Thu, Nov 15, 2018 at 5:23 PM Lukasz Cwik <[email protected]> wrote: > >> On Thu, Nov 15, 2018 at 11:47 AM Thomas Weise <[email protected]> wrote: >> >>> In case any of this affects how artifacts are published in general, >>> please make sure that publishing to 3rd party repo continues to work. >>> >>> For example: ./gradlew :beam-runners-flink_2.11-job-server:publish >>> -PisRelease -PnoSigning -PdistMgmtSnapshotsUrl= >>> https://mycustomrepo/libs-release >>> >>> Yes, I still kept this around since I used the code that we currently >> use for publishing. >> >> >>> Thanks, >>> Thomas >>> >>> >>> On Thu, Nov 15, 2018 at 11:27 AM Kenneth Knowles <[email protected]> >>> wrote: >>> >>>> Agree on the low bar. We should just make them all 0.x releases to send >>>> the right message (don't use, and no compatibility) and not worry as much >>>> about bad releases, which we >>>> would never actually depend on in the project. >>>> >>>> QQ: What does the new -P flag do? I was also hoping to eliminate the >>>> redundant -PisRelease flag, especially for vendored deps that should really >>>> be straight line. >>>> >>> >> I found having the -PisRelease flag useful for local testing because I >> could publish -SNAPSHOT builds but it isn't strictly necessary. >> The -PvendoredDependenciesOnly enables publishing of vendored >> dependencies so they aren't part of the regular release process. The name >> could be changed to be something more appropriate. >> >> >>> >>>> Kenn >>>> >>>> On Wed, Nov 14, 2018 at 12:38 PM Lukasz Cwik <[email protected]> wrote: >>>> >>>>> Its a small hassle but could be checked in with some changes, my >>>>> example commit was so that people could try it out as is. >>>>> >>>>> I'll work towards getting it checked in and then start a release for >>>>> gRPC and guava. >>>>> >>>>> On Wed, Nov 14, 2018 at 11:45 AM Scott Wegner <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks for pushing this forward Luke. >>>>>> >>>>>> My understanding is that these vendored grpc artifacts will only be >>>>>> consumed directly by Beam internal components (as opposed to Beam user >>>>>> projects). So there should be a fairly low bar for publishing them. But >>>>>> perhaps we should have some short checklist for releasing them for >>>>>> consistency. >>>>>> >>>>>> One item I would suggest for such a checklist would be to publish >>>>>> artifacts from checked-in apache/beam sources and then tag the release >>>>>> commit. Is it possible to get your changes merged in first, or is there a >>>>>> chicken-and-egg problem that artifacts need to be published and available >>>>>> for consumption? >>>>>> >>>>>> On Wed, Nov 14, 2018 at 10:51 AM Lukasz Cwik <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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! >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Got feedback? tinyurl.com/swegner-feedback >>>>>> >>>>>
