Hi Kudu dev community, For some time now the Java build has had an experimental Gradle build ( KUDU-2066 <https://issues.apache.org/jira/browse/KUDU-2241>) along side the primary Maven build. Since then the Gradle build has been improved to support all of the necessary functionality of the Maven build and more.
There are many benefits to using Gradle as listed here: https://gradle.org/maven-vs-gradle/ Some of the benefits specific to Kudu have been: - Shading Control - We have had many issues in Maven because modules can not depend on the shaded artifacts of other modules. This resulted in the classpath at compile and test time being different from the classpath in our deployed artifacts. (KUDU-2241 <https://issues.apache.org/jira/browse/KUDU-2241>, KUDU-1780 <https://issues.apache.org/jira/browse/KUDU-1780>) - Reliable Incremental Builds - Maven can pull module dependencies from the local repository during incremental builds. Because of some of the shading issues above, this could result in different resulting artifacts depending on how/when/where the build was run. (KUDU-2043 <https://issues.apache.org/jira/browse/KUDU-2043>) - Mini-Cluster discovery: Because Maven can use locally installed module jars in incremental builds, modules other than kudu-client can not discover the kudu binaries. This happens because the search is started from the ~/.m2 directory where the installed kudu-client jar is instead of the project directory. See here <https://github.com/apache/kudu/blob/master/java/kudu-client/src/test/java/org/apache/kudu/client/TestUtils.java#L93-L98> for details. - Gradle Wrapper - We can upgrade our gradle version without breaking any build environments. This prevent's us from being stuck on a lower build version for compatibility purposes. - Dependency updates - The Gradle build can indicate when newer versions of libraries are available. This has been used to keep Kudu dependencies current. - Distributed testing - A WIP patch for running dist-test on the java tests is posted in Gerrit here <https://gerrit.cloudera.org/#/c/9932/>. - Future Benefits - The flexibility of Gradle will allow for faster more reliable builds in the future. - Example: Precise testing control so we can run parallel local tests. - Gradle is being improved upon a lot with regular feature releases. I would like to propose the following plan to make Gradle the primary build for Kudu: 1. Fix any issues or gaps that remain with the Gradle build - Please experiment with the Gradle build and open Jiras about any issues you find or improvements that should be made. - See the README <https://github.com/apache/kudu/tree/master/java#building-with-gradle> for some tips on using Gradle (I will update documentation to be more robust). 2. Use Gradle as the default build in Jenkins pre-commit - I am testing this now and fixing any issues. 3. Change documentation referencing Maven to use Gradle instead - This includes releasing documentation. 4. Release Kudu 1.8 using Gradle in place of Maven 5. Remove the Maven build from the project - This shouldn't be immediately but maintaining two builds is a pain, so the Maven build should be removed at some point. Please let me know your thoughts on the above proposal and plan. Thank you, Grant -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
