I don't modify Calcite often enough to deserve a full vote, but I am +0.5 as an occasional contributor.
Beam transitioned from Maven to Gradle. We saw clean build times speed up by 5x or so. And of course clean builds are irrelevant for correct build systems, as their whole purpose is to build what is necessary from any starting state and not rebuild anything not necessary. The time savings for real workflows with lots of rebuilding after just a couple files edited is much greater. Gradle is mature and has all the plugins you need, and it is easy to write custom logic (groovy versus xml) or even a plugin if something is not quite what you need. There are no technical reasons not to switch, but if some portion of your community prefers Maven then it has a cost because they will have a harder time contributing to the build system and will be frustrated at learning a new command-line interface. That matters a lot. I have some advice if you go ahead: - Do *not* try to do a byte-for-byte compatible build. We did that, somewhat. It added a ton of migration time and complexity for almost zero value. - *Do* try to learn Gradle and make your build as simple and canonical as possible. We did not do that. Instead we have a highly custom build setup, even when we are doing ordinary things. It means only a few specialists really work on our build. I think the migration can be quick and easy if you allow it to be. I'd be happy to help here and there. Kenn On Sun, Mar 10, 2019 at 3:13 PM Francis Chuang <[email protected]> wrote: > I don't have an opinion on this, as I don't actively contribute to > Calcite. However, when I built the last few Avatica releases, it took a > while for maven to produce the build. If moving to Gradle yields > performance improvements, I hope Avatica can also be moved to Gradle too. > > Francis > > On 11/03/2019 9:00 am, Michael Mior wrote: > > 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 > > [email protected] > > > > Le dim. 10 mars 2019 à 05:35, Vladimir Sitnikov > > <[email protected]> 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 > >
