Replace the Ant build with Gradle, output verified byte-identical#326
Replace the Ant build with Gradle, output verified byte-identical#326pacmano1 wants to merge 4 commits into
Conversation
Pure file moves, no content changes: every rename is 100% similarity. Verify with: git show --stat -M100% (1,806 renames, 0 insertions, 0 deletions). Java sources to src/main/java, resources to src/main/resources, tests to src/test/java and src/test/resources, in every module (donkey already used this layout). Refs OpenIntegrationEngine#52 Signed-off-by: Finnegan's Owner <44065187+pacmano1@users.noreply.github.com>
Native Gradle 8.14.1 build (wrapper committed, distribution checksum pinned): same artifacts, same locations. server/setup is the assembled distribution, server/dist the extension zips. The Ant build files are replaced by tombstones pointing at ./gradlew; Eclipse project files are retired in favor of native IDE Gradle import. CI builds with gradle/actions/setup-gradle (wrapper validation, SHA-pinned action) and the Dockerfile builds with the wrapper. Cross-project staging uses per-project artifact inventories (Gradle-9-safe; no cross-project configuration resolution, no exec(Closure); --warning-mode all carries no Gradle-9-fatal classes). Output parity with the Ant build was verified archive-by-archive; evidence and tooling arrive with the dependency commit. Note: this commit references the version catalog introduced by the next commit and does not build standalone; the branch head does. The .gitattributes line-ending rules follow PR OpenIntegrationEngine#214 by NicoPiel. Refs OpenIntegrationEngine#52, OpenIntegrationEngine#214 Signed-off-by: Finnegan's Owner <44065187+pacmano1@users.noreply.github.com>
pacmano1
force-pushed
the
gradle-migration
branch
2 times, most recently
from
3e2b399 to
fb98f2d
Compare
|
Looking good! Tests pass, CI passes, released binaries are byte-identical with the main ant build. |
374 of 419 vendored jars are replaced by version-catalog coordinates (gradle/libs.versions.toml). Every adopted coordinate was SHA-1-matched byte-identical to the vendored jar it replaces; resolution is non-transitive so the runtime artifact set stays exactly the audited set, and gradle/verification-metadata.xml enforces sha256 on every resolution. gradle/vendored-layout.json maps each artifact to its historical place in the distribution; per-project placement checks (aggregated by verifyVendoredParity, required by every build and by setup assembly) fail if a resolved artifact lacks a placement. The 45 jars without a byte-identical published artifact stay vendored, each with an evidence-based reason in tools/build-parity/jar-provenance.json. Distribution output is verified entry-content identical to an Ant build of this branch's parent commit: 490 of 490 archives, zero differences beyond tool metadata. Tooling and methodology in tools/build-parity/. Refs OpenIntegrationEngine#52, OpenIntegrationEngine#146 Signed-off-by: Finnegan's Owner <44065187+pacmano1@users.noreply.github.com>
pacmano1
force-pushed
the
gradle-migration
branch
from
fb98f2d to
3944b31
Compare
jonbartels
left a comment
jonbartels
left a comment
There was a problem hiding this comment.
Can the file moves be refactored to a separate PR. It is good to move the project to the standard gradle layout. However it would make the first commit smaller. https://docs.gradle.org/current/dsl/org.gradle.api.tasks.SourceSet.html and main.java.srcDirs
So that would be one PR with a non-standard layout. then a second PR would move to the standard layout. It could also be one PR with multiple commits showing the addition of gradle, removal of JARs, then move of project files.
I think this PR has the same too-large problem one of the earlier Nico PRs had
There was a problem hiding this comment.
Should this JAR be committed? What is typical for Gradle? Surely a depdendency manager can download its own jars?
There was a problem hiding this comment.
The purpose of the gradle-wrapper.jar is to replace a standard Gradle installation. So someone could clone the repo without Gradle being installed, and build the project. So it should be committed along the gradle-wrapper.properties file.
From the official Gradle documentation:
To make the Wrapper files available to other developers and execution environments, you need to check them into version control.
Wrapper files, including the JAR file, are small. Adding the JAR file to version control is expected. Some organizations do not allow projects to submit binary files to version control, and there is no workaround available.
Added note about potential file path error on Windows during javadoc step. Signed-off-by: Jon Bartels <jonathan.bartels@gmail.com>
4 participants
Refs #52.
This replaces the Ant build with a standard Gradle build in one verified step. The full write-up, what changed, what is and is not byte-identical, how it was built, known limitations, and how to re-run every check, is BUILD-MIGRATION.md at the repo root. Start there.
The short version:
git show --stat -M100%confirms zero content change), the build swap, and the dependency swap. Of the three, only the head commit builds; they are split for reviewability, and squash-on-merge is fine.tools/build-parity/jar-provenance.json. Every build re-verifies checksums and distribution placements.Verification is self-serve:
tools/build-parity/contains the comparator, the provenance audit, and a recipe for every route. The Ant baseline hash file (oie-release-verifier format, uncompressed SHA-256e54cb2ef8c30ea887fb6752fc83a4dbf9fd818de3267177d29d6d2a1eaf3f6e4) is published here. A second maintainer re-running the dual-build recipe before merge is invited.Draft while review runs its course.