Thanks Vladimir! Sorry for the delayed response. I haven't looked over the artifacts myself in detail, but the diffs you mention don't raise any red flags for me. I'm not sure what you mean by the "docker module" though. As far as cleaning up the artifacts, I assume we should implement a similar policy to that of releases and clear out old RCs. These aren't maintained in the Apache Archives, but I also don't see an obvious need to keep them around.
-- Michael Mior mm...@apache.org Le lun. 22 juil. 2019 à 04:54, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > > 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.
