> Gradle makes that possible with virtually zero configuration. Can't agree more. In the long term, Gradle has lower maitainence cost than Maven (look at the gradle scripts and Maven pom file), let alone the performance improvement.
- Haisheng ------------------------------------------------------------------ 发件人：Vladimir Sitnikov<sitnikov.vladi...@gmail.com> 日 期：2019年07月03日 00:01:31 收件人：Apache Calcite dev list<dev@calcite.apache.org> 主 题：Re: CALCITE-3158, Avatica: migrate build system to Gradle Michael> I agree with Julian's point about adding maintenance Michael> overhead. Frankly speaking, it is (still) extremely hard for me to decipher Julian's mail. It is so dense that I can't really understand the meaning. For instance: Julian>Proof that the amount of knowledge required to maintain Avatica and Calcite is straightforward I could read "Proof" as both noun and verb. Both variations produce sense to me: a) (Please) Proof that the amount ... b) (the) Proof that ... is straightforward (as follows) Julian>There are more lines of code, the code is getting older, and the number of technologies is increasing I can't understand if that is a generic statement regarding all the changes in Avatica thought the recent 5-10years or if that statement classifies Gradle PR only. Julian>I don’t know how you can refute that claim I know neither because, well, I don't understand the preceding sentences :( Michael> Is there any reason we need to use Kotlin for the build script? Michael> Couldn't this just be more Java? Gradle has two options: Groovy or Kotlin. I know of no Java-based build system. Why do you ask for that? Do you have ideas? I'm sure Kotlin wins when compared with Groovy. My experience shows that: a) StackOverflow, Google, and Gradle documentation are good enough to develop Gradle scripts. Of course the maintenance is simpler than writing from scratch. b) Gradle provides explicit APIs for customization which is much simpler than extending Maven c) Gradle scripts can be debugged as usual code. That is I can put a breakpoint right in the middle of Gradle build script, I can watch variables and play with them. Can you do that in Maven? I doubt so. Michael>I agree with Julian's point about adding maintenance Michael>overhead. Even though you both are right that "a new technology must have some costs", I strongly disagree that Gradle for Calcite/Avatica would make maintenance more complicated. I have shown numerous examples, and there are multiple JIRA tickets regarding surprising mvn outcomes which Calcite committers can't fix. We could have a Google Hangouts talk if you will. It might be a nice point to spark an online conversation. I can share the screen and walk though basic steps. However, (even though I try to be extremely inclusive) I really fail to believe that you "haven't really encountered the same problems with Maven". I guess it means that I just failed to explain the problems in a right way. For instance. Can I pick the very first example of https://issues.apache.org/jira/browse/CALCITE-2905 ? 1) If you change code in "core" and or "linq4j" modules and you want to check "cassandra", you need to "mvn install" those modules first otherwise "cassandra" would use "core" from the local Maven repository As you say, you "haven't encountered that". Does that mean you always build and run all the tests and Calcite modules? I doubt so. Does that mean you can make changes to "linq4j", and immediately run core tests WITHOUT "mvn install" on linq4j? I doubt so. Does that mean you take "for granted that one must manually perform mvn install in linq4j; and only then run tests in core"? It does not have to be like that. That is especially true for cross-project changes. For instance, if you make a change in Avatica, you can't easily run Calcite test via Maven. In the same way, you can't really run a Drill test right after you modify a class in Calcite. Gradle makes that possible with virtually zero configuration. Once upon a time I was investigating Calcite-Drill planning issue (e.g. https://issues.apache.org/jira/browse/CALCITE-2223 ), and it was pity how developer experience of "Calcite consumers" was. One have to invent custom versions in poms, rebuild the projects in the right order. Sometimes I failed to rebuild the important ones and so on. It would be so much easier I could just launch a Drill test I want. I'm sure that feature alone dramatically reduces maintenance costs as it greatly simplifies cross-project testing (e.g. Avatica-Calcite, or modules within Calcite, or Calcite-Drill, or Avatica-Calcite-Drill or whatever else). Vladimir
