I currently sit at -0 on this as I haven't found Maven too cumbersome personally. However, I think you make some valid points. Hopefully it won't take too long to try this and then we can see what the actual impact on build times will be. It would also be good to hear from others doing regular Calcite development.
-- Michael Mior mm...@apache.org Le dim. 10 mars 2019 à 05:35, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > > Hi, > > I wonder what you think of migrating Maven to Gradle. > > I think one of the main points for having Gradle would be: > 1) Eliminate "mvn install" for local testing. Calcite consists of > multiple Maven modules, however Maven always uses jars from the local > repository. > That is if you modify a file in "core", then you can't just invoke mvn > test from "cassandra". You have to "mvn install" "core" first. > There are workarounds (e.g. "mvn install" all the modules every time) > > In Gradle, "multi-module" build feels more like "always composite > module". In other words, even if you invoke "build" task from within > "core" module, Gradle would find all the modules in current project, > it would compute all the dependencies and build accordingly. > In my opinion it makes a big difference. > > There's a support for cross-project incremental builds as well. I > haven't used that, however the idea there is that one can have > "calcite" and "drill" as different Gradle projects, however one can > modify a file in Calcite and invoke "build" from a Drill folder. It > would build Calcite first. > > 2) Maven task/plugins often fail to declare inputs/outputs. This > causes issues like MSHARED-394: Avoid rewrite of destination in > DefaultMavenFileFilter#filterFile when producing the same contents. > Gradle embrases tasks authors to declare inputs outputs (e.g. files or > just property values) and it enables the build system to track stale > tasks. > > Gradle supports "buildSrc" folder which can contain code that is > available to the buildfiles of a current project. It enables to > express build logic in a much more sound programming language than > XML. > > Vladimir
