Michael> is not proposing to change the
Michael>structure of modules within both projects, merely to have the code
for
Michael>both in a single repository.
I propose to integrate them into a single build, and keep the set of the
published jars.
However, the modules and dependency structure could be kept as is.
We might want to rename folders like
calcite-core
calcite-linq4j
..
avatica-core
avatica-server
However, I am not sure it is that important to discuss folder names now.
The idea is that as you "open Calcite in IDE, you see both Avatica and
Calcite modules"
Michael>Is there any reason we couldn't have a separate release schedule if
Michael>both projects are in the same repository?
A different schedule means Calcite must support at least two different
Avatica versions.
In other words, if we allow clients to update Avatica at their will, then
we should allow them building Calcite with different Avatica versions,
which implies Calcite test code should succeed for multiple different
Avatica vesions.
That makes it harder to write tests: we have to execute tests with two
different Avatica releases (or even more than two).
There are at least two sources for complexity:
a) We have to write tests that tolerate multiple versions. For instance,
"if (avatica.18+) {...}" and so on.
That is not really trivial, especially taking into account some of the
tests are created with non-yet-popular
technologies like Quidem where you can't really google solutions. So the
"trivial" task of "making a test to expect two possible outcomes"
becomes less trivial as you try to pass the version from GitHub Action to
Gradle to JUnit to Quidem to no-one-knows-which class.
If we support one Avatica version only, that is not needed. We just patch
the test in Avatica and Calcite and that is it.
Single repo avoids "Gradle vs Quidem" dance.
b) If we claim that we support 5 different Guava versions, 3 different JDK
versions, 2 different Avatica versions,
then we have to execute 5*3*2 = 30 combinations of the tests.
That is not really a full matrix, however, things get way easier if we
support one Avatica version only.
The amount of tests we need to do during a proper release is much less, and
it is easier to commit
changes that touch Avatica and Calcite at the same time.
Vladimir
