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
