Java 17 is not a priority to me. And, there were few changes in Avatica
over the time range in question, so there is no benefit to having
releases "for free". Most likely, having additional releases for Avatica
would have created _more_ work for me downstream through my employer and
Phoenix's integration of Avatica.
This is all coming back to my opinion that Avatica and Calcite, though
governed by the same organization, do not have to have their development
done in lock-step. Yes, there can be benefit to combining build metadata
and configuration, but I do not believe the number of developers nor the
automated builds for Avatica require such consolidation (Avatica is just
not that complicated).
I am still upset from the porting of Avatica to Gradle and the amount of
effort which I came into because of the opinion that "Gradle is better".
I burned at least one week just to get Avatica "back" to a state where I
could actually do development on it and downstream integration was again
working. It's extremely hard for me to look at your suggestions to move
the code base and change the build configuration, and not feel like I'm
going to end up having even more debt to pay down.
I should apologize for my heated remarks earlier; I was quite upset that
my original comment about combining avatica and avatica-go was taken as
I was OK with combining calcite and avatica.
tl;dr Avatica is not a high-activity project and that is OK. I do not
want to worry about a shared build configuration between Calcite and
Avatica because I want to be able to make changes to Avatica _that make
sense for Avatica_. I don't have nearly as much time as I wish I had to
write new code; this is why I am not in favor of such fundamental change
without a very good reason (acknowledging: this is where you and I
disagree, there are large problems and the changes you are suggesting
would fix those).
Thanks for putting the poll out, Jacques.
On 11/10/21 4:33 PM, Vladimir Sitnikov wrote:
Josh>because I genuinely do not see how this approach
Josh>creates more code that needs to be written than if the projects were in
Josh>the same repository.
Compare
https://github.com/apache/calcite-avatica/blob/4cf769f8ee32bb3520604e4f3284e6f233f90276/build.gradle.kts
and
https://github.com/apache/calcite/blob/6d51d277b158ff7073f29ada4a96a7a74c0b46fc/build.gradle.kts
Those are duplicate files, and I had to create them twice.
If the code was co-located in a single repository, then a single copy of
the file would be enough.
John>(I am to assume) is a personal motivation for yourself.
Everybody who contributes to the build scripts, dependencies, etc, would
want to avoid duplication of their work.
John>Avatica 1.17.0 was released Jun 2020, 1.18.0 in May 2021. Calcite had 3
John>releases of its own between these.
In other words, Avatica could have three releases **for free**
Of course, you might argue there's "non-trivial procedure for releasing
Calcite",
however, I would claim it does not have to be that way.
"lots of manual steps for the release" add zero to the quality of the
release.
Of course, we might disagree here as well, however, if releasing Calcite is
painful,
then "forking Avatica into a different repository" is a wrong solution.
John>I can still build Avatica with Gradle 6.8.1.
Go ahead and try building Avatica with Java 17.
You will fail quite fast. Have a fun day.
Vladimir
