The performance improvement with Gradle is appealing. I would like to give it a try.
- Haisheng ------------------------------------------------------------------ 发件人：Vladimir Sitnikov<[email protected]> 日 期：2019年07月01日 21:11:41 收件人：Apache Calcite dev list<[email protected]> 主 题：CALCITE-3158, Avatica: migrate build system to Gradle Hi, Sorry for the long mail. It has three basic parts: "URLs for Gradle PR", "Motivation/new features", "build time comparison". >> Urls for Gradle PR I've started a PR for migrating Avatica build system from Maven to Gradle: https://github.com/apache/calcite-avatica/pull/104 I've put a list of "todo items" at the top of PR104. Feel free to suggest new items (or remove items). Comments/reviews are welcome. Some of the Gradle benefits can be found in https://issues.apache.org/jira/browse/CALCITE-2905 As of now PR is good enough to try how Gradle build feels. It builds the project, loads it to IDE, enables to execute tests, it can push Avatica jars to local Maven repository. It can push jars to the Nexus repository (e.g. for release purposes). If you are brave enough, you could start right from "./gradlew prepareVote". It would build all the things, and publish the artifacts to SVN/Git/Nexus services (you could start stub SVN/Nexus instances via https://github.com/vlsi/asflike-release-environment ), and it would print a draft "release vote" mail with all the urls filled in (see https://github.com/vlsi/calcite-avatica/blob/gradle/release/build.gradle.kts#L23 ) Just a side note: current release procedure has no way to smoke test the process. With my PR one can divert publish URLs to the test servers, so even non-committers can do a release and compare if their results match "the official" ones. My idea is to keep builds reproducible, so source/binary artifacts produced by different people should have the same SHA512. >> Motivation/new features If you are new to Gradle, you might find the following set of commands useful (not everything works in Avatica's build, yet lots of basic commands do): https://github.com/vlsi/jmeter/blob/gradle/gradle.md Frankly speaking, I find Gradle commands are simpler to discover and simpler to use than their Maven counterparts. For instance, `gw tasks` (gw comes from https://github.com/dougborg/gdub) provides a list of "documented" tasks. then `gw <taskname>` invokes the task. gw jar # builds the jar gw checkstyleMain # executes Checkstyle gw spotbugsMain # executes Spotbugs gw rat # executes RAT, and so on. Note: it does not mean you have to use 100 different commands, but you can run individual tasks rather than Maven's "all-in-one install" >> Build time comparison Absolute values do not matter much, but those are taken from Macbook, Late 2013, 2,6 GHz Intel Core i7. Note: major time is consumed by checkstyle, compilation, and tests. TL;DR is Gradle does not make things slower, and sometimes it makes build faster. 1) "Repeated build of avatica-core without modifications" mvn package -DskipTests: 18sec, 24sec, 21sec, 18sec gw build -x test: 14sec, 1sec, 1sec, 1sec As you see, Gradle recognizes that nothing should be compiled. Maven seems to perform checkstyle and full compilation even for no-op cases. 2) "Alter string literal in AvaticaStatement#checkOpen and build with tests" mvn package: 20sec, 19sec gw build -x test: 15sec, 15sec, 15ec 3) "Alter string literal in server/...HttpServer#stop and build with tests". "... clean" is performed once before the first measurement. Two points here: 3.1) "clean" build is comparable (even though `clean` should be extremely rare) 3.2) Gradle figured out that change in server/...HttpServer#stop does not impact core, thus it avoids "core" compilation, tests, etc. mvn package: 56sec, 48sec, 48sec gw build: 50sec, 22sec, 22sec Vladimir
