Now that the NeedsRunner tests are running via Gradle I support removing
the Java maven precommit.

Lower latency, simpler config, and more available Jenkins workers FTW.

Now let's fix the --rerun-tasks bugs so we can do even better.


On Wed, Mar 7, 2018 at 11:21 AM Lukasz Cwik <lc...@google.com> wrote:

> 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)?
>
>
> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>

Reply via email to