Hi Vladimir, First of all thanks a lot for the great work so far!
I never used Gradle before but I am rather convinced with all the positive points that you raised through the various discussion so far. Although Maven seems to be the most popular build tool, I followed various discussions highlighting the advantages of using Gradle and it seems that people are rather happy with it. I think Julian raised the point about the artifacts because, as everybody else, he is concerned that we may break something during the migration process. In the end what it matters is doing our best to predict every corner-case; peoples' feedback as well as your analysis help a lot towards achieving this goal. At the moment, I do not have much free time to properly review the artifacts; I will try to find some time next week if the case remains open. Best, Stamatis On Mon, Jul 22, 2019 at 10:54 AM Vladimir Sitnikov < [email protected]> wrote: > Julian>Before we accept this, I would like to make sure that the source > Julian>artifacts are identical > > That is interesting. > I thought "developer experience" was more important than a mythical > "identity of the artifacts". > > Unfortunately, "Identical artifacts" sounds more like an excuse to avoid > looking into > the suggested build script improvements. > The build is almost complete to fully replace Maven, and the only feedback > I get is like "make the artifacts identical before we even try it". > > I would make a RC via Gradle soon. > > Note: I still have no idea on what "docker" module is for, however I do > not think it is vital. > > I see there are lots of old files at > https://dist.apache.org/repos/dist/dev/calcite/ > Do we need to keep them? I'm inclined to cleanup /dist/dev/calcite folder. > > ---- > > Nevertheless, I've implemented an automated comparator that builds > artifacts by both build systems > and commits the artifacts to a temporary Git repository. Then it calls > `git format-patch` to compare the results. > > Of course there are differences, however I would claim Gradle-generated > artifacts are strictly better. > > Note: you can generate artifacts and inspect them via ./gradlew clean > buildAllArtifacts commitGradleArtifacts compare > The extracted artifacts are placed to $rootDir/exploded and $rootDir/git > > I compare the following artifacts: *.jars (except javadoc), -src.tar.gz, > and *.xml. > Gradle-based build additionally generates -src.zip (with CRLF). > > Differences are as follows (the patchfile that compares Maven vs Gradle > artifacts is attached): > 1) Maven build misses *-test.jar for certain projects. > Frankly speaking, it would be nice to completely remove release of the > test artifacts. However test jars are used across projects, so we can't > just remove the test jars yet. > For now I've made Gradle to generate test jars in a consistent manner. > > 2) Maven's naming of "-shaded.jar" files is inconsistent. > For instance: avatica-tck-1.16.0-SNAPSHOT-shaded.jar, however shaded/core > produces avatica-1.16.0-SNAPSHOT.jar (which is shaded) > > 3) Maven artifacts include "resources" to -sources.jar. > Technically speaking, I do not see reasons to include non-java files to > the -sources.jar > Releasing extra files increase the surface of potential license > violations, and > I don't think releasing files > like avatica-core-1.16.0-SNAPSHOT-test-sources.jar/log4j.properties help > something > > I'm not sure what sense does it make to include *.proto files > to avatica-core-1.16.0-SNAPSHOT-sources.jar. > > 4) Gradle-generated MANIFEST.MF do not include > Build-Jdk, Created-By, Built-By. > This is done for making the build reproducible. > > 5) Gradle-generated pom.xml do not contain <build> information. It does > not contain <scope>test</scope> dependencies as well. > > 6) License files are included in a different way. Gradle build includes > both LICENSE and NOTICE files from third-party dependencies. > Those are added to /licenses/ folder (or META-INF/licenses/ for jars). > > 7) Maven-generated artifacts will probably be inconsistent with regards > to "end-of-line" and "executable" across operation systems. > > 8) Maven-generated MANIFEST.MF contain non-existing URL's like: > Implementation-URL: https://calcite.apache.org/avatica/avatica-metrics > > I've no idea where that link comes from, and I guess Maven generates that > automatically by appending "<url>" from the parent pom with project names > for subprojects. > If we really need Implementation-URL, we should probably include valid > urls. > For now I just skip that attribute in Gradle. >
