Proof that the amount of knowledge required to maintain Avatica and Calcite is straightforward. There are more lines of code, the code is getting older, and the number of technologies is increasing. I don’t know how you can refute that claim.
The question is what we can do to resist that trend. One thing is to be sparing when we introduce technologies. Of course the Kotlin code takes effort to maintain. All code takes effort to maintain. Julian > On Jun 29, 2019, at 8:47 PM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > 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
