Re: [PROPOSAL] Preparing 2.5.0 release next week

Yes, but I never saw anyone grabbing the sources from dist in maven world but I did saw people using maven dependency plugin to grab the sources and the pom and rebuild the modules. I'm not saying it is the best practise but beam will always be maven for most java users so we must be very careful

Re: [PROPOSAL] Preparing 2.5.0 release next week

Hi Luke, you are right, from a Apache perspective, the only required artifacts is the source tarball on dist (that should be buildable). There is no requirement for the ones on Maven, it's more for convenience for our users. Regards JB On 04/09/2018 09:56 PM, Lukasz Cwik wrote: > Romain, I was

Re: [PROPOSAL] Preparing 2.5.0 release next week

Romain, I was under the impression that the source tar ball that is uploaded to www.apache.org/dist/ is required to be buildable and is a separate deliverable from the artifacts (jars (source/test/javadoc/...)/poms) uploaded to https://repository.apache.org/service/local/staging/deploy/maven2.

Re: Gradle Status [April 6]

Simplifying examples/java precommit is encompassed in BEAM-4033. Both you and Kenn pointed to the same thing. To my knowledge it is the only place where we have such a loop that generates tasks. On Mon, Apr 9, 2018 at 3:37 PM Romain Manni-Bucau wrote: > > > Le 9 avr. 2018

Re: Gradle Status [April 6]

Le 9 avr. 2018 21:04, "Lukasz Cwik" a écrit : Romain, can you clarify by the weird task naming? (Give some examples using our current project and Gradle and what you would have expected.) Sure

Re: Gradle Status [April 6]

Hi Luke, let me take a concrete example. I'm developing a Beam extension. Most of the time, I will ask myself: 1. How do I do the build.gradle and include my extension in Beam project 2. How do my extension is compile (the equivalent of maven-compiler-plugin) and how to deal with dependency

Re: Python postcommit and precommit

The shell scripts still exist instead of using Gradle. Migrating to Gradle as the build system hasn't addressed this (only change in the Gradle migration was an improvement where Gradle now creates a virtualenv automatically for building). Alan, any plans to integrate more closely with Gradle

Re: Gradle Status [April 6]

Romain, can you clarify by the weird task naming? (Give some examples using our current project and Gradle and what you would have expected.) On Mon, Apr 9, 2018 at 2:49 PM Romain Manni-Bucau wrote: > +1 gradle not being mainstream - and even more in beam scope than other

Re: Gradle Status [April 6]

+1 gradle not being mainstream - and even more in beam scope than other java scope - it must stay simple. I know that personally it takes me x2 or 3 to say "ok ill fork" a project using gradle, in particular with custom scripts and not only parent/module scripts. If needed we can write custom

Re: Gradle Status [April 6]

My phrasing sounded a bit too much like adding a blocking condition. I absolutely don't want to do that. Our maven build was far from clear, and had lots of tech debt and spooky action at a distance, I just want to emphatically agree with JB's sentiment that we have an opportunity to improve it

Jenkins build is back to normal : beam_SeedJob #1455

See

Re: Gradle Status [April 6]

Fixed up prior e-mail. On Mon, Apr 9, 2018 at 1:50 PM Lukasz Cwik wrote: > JB, learning the build system in a project is hopefully avoided by most > users if the contribution guide can clearly explain what users need to do. > But for everyone else who wants to change a

Re: Gradle Status [April 6]

JB, learning the build system in a project is hopefully avoided by most users if the contribution guide can clearly explain what users need to do. But for everyone else who wants to change a dependency version or add a dependency it should be as simple as copy/paste (which I believe it already

Build failed in Jenkins: beam_SeedJob #1454

See -- GitHub pull request #5058 of commit d515a361feb60331dd69f259ebba8379bb354b88, no merge conflicts. Setting status of d515a361feb60331dd69f259ebba8379bb354b88 to PENDING with url

Re: Gradle Status [April 6]

Huge +1 to the idea of investing in simplification and polish of the Gradle files before considering the migration complete. 1. build.gradle files should be as close to straight-line configuration as possible: - You should be able to understand a module's build easily, locally, without knowing

Build failed in Jenkins: beam_SeedJob #1453

See Changes: [lcwik] Attempt to produce release artifacts. [lcwik] Sign the published artifacts. [lcwik] Rename a few of the projects so that the artifact names are correctly [lcwik] Rewrite even more names.

Re: Gradle Status [April 6]

Hi all, I did multiple gradle build since last week and I would like to share one of my concern: it's about the communities. If I think our users won't see any change for them due to Gradle build (I think that most of our users will still use Maven with artifacts provided by Gradle), I'm

Re: Gradle Status [April 6]

On Sat, Apr 7, 2018 at 12:43 Reuven Lax wrote: > So if I understand correctly, we've migrated all precommit, most > postcommits, and we have a working release process using Gradle. There are > a few bugs left, but at this pace it sounds like we're close to fully > migrated. > >

Re: [PROPOSAL] Preparing 2.5.0 release next week

On testing on the PR branch. Regards JB On 04/09/2018 04:06 PM, Lukasz Cwik wrote: > > > On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau > wrote: > > I got the same with that PR applied and the previous command. Is using > your

Re: [PROPOSAL] Preparing 2.5.0 release next week

On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau wrote: > I got the same with that PR applied and the previous command. Is using > your fork needed? No, you can also use https://github.com/apache/beam/pull/5048 > Is there any PR to import it? > Yes,

Re: [PROPOSAL] Preparing 2.5.0 release next week

I got the same with that PR applied and the previous command. Is using your fork needed? Is there any PR to import it? In any case master is not ready to be released with that yet - to come back to the actual topic. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book

Re: [PROPOSAL] Preparing 2.5.0 release next week

Romain, The gradle based release process has an open PR in https://github.com/apache/beam/pull/5048 to merge to master. I thought you were running the commands from https://github.com/lukecwik/incubator-beam/tree/gradle On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau

Re: [PROPOSAL] Preparing 2.5.0 release next week

@Lukasz: same with gradlew and release option, pom is empty (no parent, no dependencies, no more description - needed since central poms use that for doc purposes). Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: [PROPOSAL] Preparing 2.5.0 release next week

Is everything needed merged into master? If so, why don't we try doing it with Gradle, but "fail fast" back to Maven if something doesn't work. If something doesn't quite work I don't think we should delay 2.5.0 while we fix it, when we can still do 2.5.0 with Maven. Reuven On Mon, Apr 9, 2018

Re: [PROPOSAL] Preparing 2.5.0 release next week

I would rather have the community try doing the 2.5.0 release with Gradle and to fix the issues while people are currently focusing on the migration and not 6 weeks from now when the 2.6.0 release starts. We can always fallback to Maven if the community thinks its not ready. If we go with using

Re: [PROPOSAL] Preparing 2.5.0 release next week

Surely did something wrong launching: gradle [build] publishToMavenLocal $ cat ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom http://maven.apache.org/POM/4.0.0; xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0

Re: [PROPOSAL] Preparing 2.5.0 release next week

I will check now what's the pom status, if they are ok it can be worth testing gradle Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: [PROPOSAL] Preparing 2.5.0 release next week

Hi Reuven, that was on of the question. I proposed to stay with Maven for 2.5.0 and switch to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it may worth to try 2.5.0 with Gradle. Regards JB On 04/09/2018 02:27 PM, Reuven Lax wrote: > To the folks working on Gradle last week

Re: [PROPOSAL] Preparing 2.5.0 release next week

To the folks working on Gradle last week - are we at the point where we can try running this release purely using Gradle, or should we wait until 2.6.0? Reuven On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré wrote: > Up ? > > Regards > JB > > On 04/06/2018 10:48 AM,

Build failed in Jenkins: beam_Release_NightlySnapshot #740

See Changes: [relax] Rename RowType -> Schema and move to new schemas package. [relax] Add classes for SchemaRegistry and SchemaProvider. [relax] Add SchemaCoder, some more detail in

Re: [PROPOSAL] Preparing 2.5.0 release next week

Up ? Regards JB On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote: > Hi guys, > > Apache Beam 2.4.0 has been released on March 20th. > > According to our cycle of release (roughly 6 weeks), we should think about > 2.5.0. > > I'm volunteer to tackle this release. > > I'm proposing the