Are there instructions for how to do this? I would like too switch my IntelliJ over to Gradle (it's still setup using Maven)
On Wed, Mar 7, 2018 at 1:29 PM Kenneth Knowles <k...@google.com> wrote: > SGTM. I should also say that every day is Gradle fixit day for me, as I > have been using only Gradle (with IntelliJ) for a while :-). If anyone is > hesitant, definitely it is ready to be used for normal dev. > > Seems like changing the messaging in onboarding docs is the main thing to > fixit. > > Based on https://builds.apache.org/view/A-D/view/Beam/ and our failure > spam level the performance tests are mostly not healthy anyhow. So is there > any high level blocker to switching them or is it just someone sitting down > with each one? > > Kenn > > > On Wed, Mar 7, 2018 at 1:22 PM Lukasz Cwik <lc...@google.com> wrote: > >> Largest outstanding areas are: >> * Documentation relevant to the contributors guide/release process/testing >> * Performance tests >> >> There has been good progress towards: >> * Release artifact validations and generation >> * ValidatesRunner post commits >> * Pre commits >> * Container builds >> >> >> On Wed, Mar 7, 2018 at 1:19 PM, Reuven Lax <re...@google.com> wrote: >> >>> 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 <k...@google.com> 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 <lc...@google.com> 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 < >>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>
