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>

> 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