I have created the artifacts and sent out a vote thread. On Thu, Nov 15, 2018 at 5:23 PM Lukasz Cwik <lc...@google.com> wrote:
> On Thu, Nov 15, 2018 at 11:47 AM Thomas Weise <t...@apache.org> 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 <k...@apache.org> 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 <lc...@google.com> 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 <sc...@apache.org> 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 <lc...@google.com> 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 <lc...@google.com> 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 <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! >>>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> Got feedback? tinyurl.com/swegner-feedback >>>>> >>>>
