Julian>The amount of knowledge required to maintain Avatica (and Calcite) is increasing even as Avatica does basically the same thing it did two years ago.
I would argue here. Below are the issues from the top of my head. They can't be solved with Maven and they would just go away. 1) Current LICENSE files produced by Avatica and Calcite fail to comply with ASF policy, and the files are out of date. Apparently, we don't have lots of engineers who know how to maintain license files. Just to remind: I ask for the license file layout in this thread, and you see how everybody knows the answer. 2) Calcite is always biting me with the need to 'mvn clean' here and there. There are cases which can't be fixed at pom.xml level, and it requires maitainer to remember and dance every time. There are number of 'profiles' in the build script that are present as workaround only. 3) Multi-module support in Maven is so-so (see CALCITE-2905). One have to remember to invoke 'mvn install' in the right order. 4) Multi-project support in Maven just does not exists. Testing the impact of Avatica feature branch changes to Calcite is complicated: you need to customize pom version in Avatica, install it, then you update Calcite's pom to use that version. If you make a change in Avatica, then you have to do a series of 'mvn install' just in order to propagate the change. Gradle solves the issue by enabling us to link projects so it builds dependencies automatically. Note: all of the above is something that hit us on a day-to-day basis, so the issues are not theoretical. On the other hand, your 'The amount of knowledge required to maintain Avatica (and Calcite) is increasing' is purely theoretical. It is good you care of maintenance costs, and it is sad you resort to the same theoretical statement with no justification examples. Julian> adding Kotlin-based tests to Calcite a while ago As far as I can see, those turn out to be fine: it does not require effort to maintain. Vladimir
