I am totally OK for doing the unification after the Gradle migration. Other than that, I had a quick look and left some comments directly in the PR. I will try to test it when I find some time.
On Thu, Nov 14, 2019 at 10:27 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > The Gradle build scripts are ready ( > https://github.com/apache/calcite/pull/1571 ) > There might be minor issues like "a resource file missing in one of the > jars", > however, I expect there will be no more major changes. > > > Unfortunately, there are changes that prevent building with both Maven and > Gradle from the same commit. > For instance, Maven uses > "core/src/main/resources/version/org-apache-calcite-jdbc.properties" for > figuring out driver version. > And Gradle build just generates CalciteDriverVersion.java > I don't want to over-engineer pom.xml files, so I did not try to make > pom.xml files buildable. > However, pom.xml files will be removed right after Gradle script is merged. > > The other change is Druid migrated from JUnit4 to JUnit5 (to enable the use > of Assumptions). > > I'm inclined to commit the change, so please feel free to review it. > > In case you missed, you can start playing with the build with the commands > that are listed in the commit message: > > https://github.com/apache/calcite/pull/1571/commits/4bbf1cdeac6e09959e027eaa482a67937228bf9d > "./gradlew tasks" could be a good start. > > The file movements/edits are minimal, so I hope it won't affect pending > PRs. > > > Note, as I said earlier, having both Avatica and Calcite in Gradle enables > us to load both projects to the IDE at the same time. > In the same way, one can test who Avatica fix impacts Calcite with a single > command line. No changes to pom.xml needed!!! > > The procedure is to clone calcite-avatica and calcite side by side, and use > -PlocalAvatica property. > > Vladimir >
