I think Alan was making progress on the Gradle build. What do people think of a "fixit" day for Gradle work? (or given that people are distributed, maybe a fixit week, where everyone takes one day from the week).
On Wed, Mar 7, 2018 at 1:17 PM Kenneth Knowles <[email protected]> wrote: > I also cannot drop everything to work on Gradle build, but maybe it isn't > that drastic anyhow. Now that we have ValidatesRunner and NeedsRunner tests > and some progress on the release, is there any other known missing > functionality in the Gradle builds? Archetypes? Docker container images? > > > On Wed, Mar 7, 2018 at 1:12 PM Lukasz Cwik <[email protected]> wrote: > >> 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 < >> [email protected]> wrote: >> >>> >>> >>> Le 7 mars 2018 20:21, "Lukasz Cwik" <[email protected]> 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 < >>> [email protected]> wrote: >>> >>>> >>>> >>>> Le 7 mars 2018 17:34, "Lukasz Cwik" <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]>: >>>>> >>>>>> >>>>>> >>>>>> Le 11 janv. 2018 23:13, "Kenneth Knowles" <[email protected]> a écrit : >>>>>> >>>>>> On Thu, Jan 11, 2018 at 8:43 AM, Romain Manni-Bucau < >>>>>> [email protected]> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>
