I am working on various projects and may not be able to pause my work for a couple of weeks while the build/test process is migrated.
What is everyone thinking about Romain's suggestion because If I'm the only person in such a situation, I would be willing to go along with the plan. On Wed, Mar 7, 2018 at 12:59 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > > Le 7 mars 2018 20:21, "Lukasz Cwik" <lc...@google.com> a écrit : > > Note that Alan Myrvold has been making steady progress making the release > process via Gradle a reality: > 1) Creating a jenkins job which can run the quickstart validation against > nightly snapshots and also can be used for release candidates ( > https://github.com/apache/beam/pull/4252) > 2) Building a release candidate using Gradle ( > https://github.com/apache/beam/pull/4812) > > Also, Gradle is the tool that has been selected already and there was a > community discussion about what was needed for the migration to occur with > a clear set of criteria. Romain, it doesn't seem like we should ignore that > criteria or are you suggesting we change that criteria (if yes, how)? > > > No, no. My goal is just to quit this state. > > Let s draft a plan: > > 1. 2.4 is released - i assume it is done with mvn here > 2. We drop all poms and jenkins mvn config > 3. We fix all build issues if so (let say in a week) > 4. Pr can nees updates but no more mvn merge > > April is gradle month :) > > Wdyt? > > > > > On Wed, Mar 7, 2018 at 10:39 AM, Romain Manni-Bucau <rmannibu...@gmail.com > > wrote: > >> >> >> Le 7 mars 2018 17:34, "Lukasz Cwik" <lc...@google.com> a écrit : >> >> Thanks for bringing this up Romain but I believe your data points on pass >> rates are only partially correct. >> >> >> Sure sure, it is mainly about my own PR which a very small % of the whole >> project ;). >> >> >> >> In the past week the Java Gradle precommit passed 46.34% of the time >> compared to the Java Maven precommit which passed 46.15% of the time. When >> I looked at these numbers in mid January they were around 37% so there has >> been some improvement. Regardless of the build tool it seems that our pass >> rates aren't stellar for the Java build and are causing the community to >> not follow best practices (wait for precommits to be green before merging). >> I know that on the website we used the mergebot to ensure that things >> passed before they were merged, should we institute this on the master >> branch or are their any other ideas? >> >> As a side note we had achieved the goals we set out to not need to >> maintain the Maven precommit and have authored the first PR to drop the >> Maven precommit: https://github.com/apache/beam/pull/4814 >> >> >> Well, I'd be for a strong switch otherwise PR will keep using maven, >> jenkins will not test the code and at the end we fail to deliver something >> consistent. So whatever tool is selected I'm tempted to say drop other >> build files and jenkins hooks references. >> >> What about doing it after 2.4 vote? >> >> >> >> On Wed, Mar 7, 2018 at 2:24 AM, Romain Manni-Bucau <rmannibu...@gmail.com >> > wrote: >> >>> Up, >>> >>> We discussed to have a strong switch to gradle or rollback to maven >>> around april to not be blocked by the build tool. I noticed gradle build >>> rarely passes on PR and kind of blurry our vision - not sure why exactly. >>> Also, PR don't always contain the gradle updates - generally >>> dependencies+plugins are added in pom.xml AFAIK, so it seems the adoption >>> is very slow to not say rejected. >>> >>> What do we do about that? When do we drop the double build maintenance - >>> whatever is picked? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> 2018-01-12 6:30 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: >>> >>>> >>>> >>>> Le 11 janv. 2018 23:13, "Kenneth Knowles" <k...@google.com> a écrit : >>>> >>>> On Thu, Jan 11, 2018 at 8:43 AM, Romain Manni-Bucau < >>>> rmannibu...@gmail.com> wrote: >>>> >>>>> 2. gradle build doesn't use the same output directory than maven so it >>>>> is not really smooth to have both and have to maintain both >>>>> >>>> >>>> I also have an opinion on this. It is useful and reasonable to be able >>>> to build even when the source is on a read-only filesystem. Maven's >>>> defaults are undesirable and require workarounds. We shouldn't mimic the >>>> behavior, but actually should set gradle up to build to a directory outside >>>> the source tree always, if we can. >>>> >>>> >>>> Hmm, which is something you can do with maven as well so not sure I get >>>> it. >>>> >>>> Also note the thread is no more about the technical points but more the >>>> sources maintenance and consistency. >>>> >>>> >>>> Kenn >>>> >>>> >>>> >>> >> >> > >
