Arch Linux

Some additional information. Following the PKGBUILD that is in asp, and building myself I get:
$ mvn --version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
Apache Maven 3.8.3 (82fa288cd4d98612c4240ab9774cb76c68f7ee2d)
Maven home: /opt/maven
Java version: 1.8.0_292, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.15.10-arch1-1", arch: "amd64", family: "unix"

So not sure where the NON_CANONICAL comes from. Michael Osipov mentions in the apache thread that they are giving the binaries, so maybe we don't need to be building the package at all?

We build from source and do not redistribute binary prebuilds. Would be less toxic if upstream just provides appropriate guidance instead of rage. We are literally just calling maven and do not fiddle at all with maven sources or dist, if the results are wrong then upstream build instructions are simply bad when using their signed source balls. A simple maven package call should yield to the same results and not require some wizardry environment deemed to be the only one that produces a "correct" variant, that's not how deterministic software and build process should work.

Anyway. How do you build that package that results in that difference?
You need to use a clean chroot -- can you try with using extra-x86_64-build build tool from devtools? Just calling those instructions in a git clone is not the same :)

I just used "makepkg -sic". I tried with "extra-x86_64-build" and got "==> ERROR: The built package (maven) is the one in the repo right now!", installed the resulting package.

$ mvn --version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
Apache Maven 3.8.3 (NON_CANONICAL)
Maven home: /opt/maven
Java version: 1.8.0_292, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.15.10-arch1-1", arch: "amd64", family: "unix"

So I have no idea, why NON_CANONICAL comes then...

What is the rationale for not distributing binary prebuilds? Do you guys read through the code and verify that it is secure before building?

NON_CANONICAL is probably set by [1] as the package is built from a tarball.

[1] https://github.com/apache/maven/blob/maven-3.8.3/maven-core/pom.xml#L223

@Odne: For some open source does not just mean to get free contributors, for us it means we have a verifiable path from source to artifact. You can audit a source and thats what people look at to do so, which is what we use to build. Trying to figure out what an arbitrary pre-built artifacts contains is less trivial no matter if signed by the same person. A simple maven package call should yield to the same results and not require some wizardry environment deemed to be the only one that produces a "correct" variant, that's not how deterministic software and build process should work. The question is not why we dont use pre built blobs, the question is why a simple build call yields to not the results that is expected. An appropriate build environment and software should do, like all the quadrillion other software and libraries we distribute and that are fully supported upstream even tho we build all ourselves without custom patches in place.

You can see in the PKGBUILD we literally do 0 modifications and simply call mvn package, if the results doesn't work as expected then its more upstream to blame as innocent downstream that try to build from source without having heavy custom patches going on.

@loqs: Yes but OP claims different results without clean chroot. I tried with having git etc available during build but that doesn't seem to make a difference.

Turns out maven is reproducible so we now have a win-win with the new build.

Make our packaged version 100% canonical but built from source by leveraging reproducible builds implications.

We use the upstream build number to build our version from source and check the resulting tarball against the official hashes. We literally reproduce the upstream binary dist bit by bit. This has multiple nice side
effects, most importantly we can dist a 100% canonical version that is bit by bit the same and therefor supported but still do not require to blindly repackage prebuilt artifacts.

This is literally the beauty of reproducible builds at play. We do not know who tries to reproduce their binary dists and we may not have any trust in their rebuilders (if there are any). We just want to produce artifacts ourselves from plain readable source that people can easier review and audit. However, upstream would like to ensure users are using something that works exactly the way they want it without margin of distro packaging. We get both at the same time now by comparing our tarball against the upstream tarball including the provided sha512 sums. This way we have a version that is canonical as it bit by bit matches their prebuilt files but still were not forced to trust their prebuilt packages by producing them ourselves from source.

Reproducible builds is love.