> As you say, you "haven't encountered that". My maven does work the same as yours in that I do have to take the steps you outlined. I just haven't found it to be burdensome.
> I know of no Java-based build system. Why do you ask for that? One of the concerns was adding another language. If this was in Java instead of Kotlin, that concern would go away. In any case, I'm not completely opposed to the change and I appreciate the effort you've put forth. Personally I prefer Gradle over Maven but I understand Julian's concerns. -- Michael Mior mm...@apache.org Le mar. 2 juil. 2019 à 18:01, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > > 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
