Let me paraphrase. You asked for proof. No proof is needed. It is self-evident.
Julian > On Jul 2, 2019, at 9:01 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > 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
