+1 I agree with JB on the process but I think overall using Gradle will bring only benefits.
> On 29. Nov 2017, at 09:44, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > -0 > > It's not for the change itself (gradle build is interesting) but for the > process used here, which, IMHO, is not clean. > > My major concern is the fact that gradle build has been merged on master > before the vote. I would have start the vote based on the discussion and PR > branch (acting as a PoC). > > I have the feeling that part of the dev community already decided to change > to gradle and pushed without waiting for the whole consensus. > > I don't want to "block" this change, but I wanted to raise my concern from a > community standpoint. > > Regards > JB > > On 11/28/2017 06:55 PM, Lukasz Cwik wrote: >> This is a procedural vote for migrating to use Gradle for all our >> development related processes (building, testing, and releasing). A majority >> vote will signal that: >> * Gradle build files will be supported and maintained alongside any >> remaining Maven files. >> * Once Gradle is able to replace Maven in a specific process (or portion >> thereof), Maven will no longer be maintained for said process (or portion >> thereof) and will be removed. >> +1 I support the process change >> 0 I am indifferent to the process change >> -1 I would like to remain with our current processes >> ---------------------------------------------------------------------------------------------------- >> Below is a summary of information contained in the disucssion thread >> comparing Gradle and Maven: >> https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0d2bbef1caf37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E >> Gradle (mins) >> min: 25.04 >> max: 160.14 >> median: 45.78 >> average: 52.19 >> stdev: 30.80 >> Maven (mins) >> min: 56.86 >> max: 216.55 (actually > 240 mins because this data does not include timeouts) >> median: 87.93 >> average: 109.10 >> stdev: 48.01 >> Maven >> Java Support: Mature >> Python Support: None (via mvn exec plugin) >> Go Support: Rudimentary (via mvn plugin) >> Protobuf Support: Rudimentary (via mvn plugin) >> Docker Support: Rudimentary (via mvn plugin) >> ASF Release Automation: Mature >> Jenkins Support: Mature >> Configuration Language: XML >> Multiple Java Versions: Yes >> Static Analysis Tools: Some >> ASF Release Audit Tool (RAT): Rudimentary (plugin complete and longstanding >> but poor) >> IntelliJ Integration: Mature >> Eclipse Integration: Mature >> Extensibility: Mature (updated per JB from discuss thread) >> Number of GitHub Projects Using It: 146k >> Continuous build daemon: None >> Incremental build support: None (note that this is not the same as >> incremental compile support offered by the compiler plugin) >> Intra-module dependencies: Rudimentary (requires the use of many profiles to >> get per runner dependencies) >> Gradle >> Java Support: Mature >> Python Support: Rudimentary (pygradle, lacks pypi support) >> Go Support: Rudimentary (gogradle plugin) >> Protobuf Support: Rudimentary (via protobuf plugin) >> Docker Support: Rudimentary (via docker plugin) >> ASF Release Automation: ? >> Jenkins Support: Mature >> Configuration Language: Groovy >> Multiple Java Versions: Yes >> Static Analysis Tools: Some >> ASF Release Audit Tool (RAT): Rudimentary (plugin just calls Apache Maven >> ANT plugin) >> IntelliJ Integration: Mature >> Eclipse Integration: Mature >> Extensibility: Mature >> Number of GitHub Projects Using It: 122k >> Continuous build daemon: Mature >> Incremental build support: Mature >> Intra-module dependencies: Mature (via configurations) > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
