Add uk.org.okapibarcode:okapibarcode:0.4.5

[gredler]

The builds for this project should be reproducible, starting with version 0.4.5.

https://github.com/woo-j/OkapiBarcode/

https://central.sonatype.com/artifact/uk.org.okapibarcode/okapibarcode/0.4.5

[hboutemy]

this is a Gradle build, I'm not an expert: I tried to reuse #156 in 1b88efc but I got "Problem configuring task :publishToMavenLocal from command line"

any idea on how to update the buildspec to match your project?

[gredler]

Thanks for the feedback! I'm very familiar with Gradle, but not familiar with this project, so hopefully we can figure it out between the two of us.

I had a look at a few other Gradle-based projects registered for reproducible builds, and also at (what I think is) the shell script which runs the Gradle builds... it appears to me that the Gradle integration relies on the "publishToMavenLocal" Gradle task to generate the JAR and POM files which are then compared against the files available publicly on Maven Central. Does this sound right?

If so, I think the issue is that the build is configured to always sign the generated artifacts (JARs, POMs) -- but of course the necessary private key isn't available to you. If you can confirm the above hypothesis, then I think the fix will be to adjust the build file to sign artifacts when publishing to Maven Central, but to not sign them when publishing to a local repository.

[hboutemy]

I committed the wip buildspec so you can test by running ./rebuild.sh wip/okapibarcode-0.4.4.buildspec at any time (works on Linux or Mac)

yes, the verification process is based on the content of publishToMavenLocal: anything that would make this publication fail would break the process, be it GPG signature or anything else

once we manage to have your build ok, it would be nice if we could describe for Gradle users what they need to do

[gredler]

Thanks! I've adjusted the build file to sign when deploying to Maven Central, but not the local Maven repository.

I've released version 0.4.5 with this improvement to aid reproducibility verification.

Looking at the WIP file, the version needs to be updated to 0.4.5, the tool needs to be changed to gradle, the JDK should be Java 17, and the "-Pskip.signing" build argument can be removed.

I'm happy to help document the Gradle requirements a bit better. Note that I've created a Gradle feature request to make all Gradle builds reproducible by default without build customization, so steps may change in the future. See: gradle/gradle#28806

[gredler]

Any luck with the adjustments? I'm not able to verify locally due to file permission issues while running rebuild.sh, but the changes mentioned above should do the trick.

[hboutemy]

buildspec updated in 204f06e
works mostly: only the javadoc hash in .module file is not ok

to me javadoc is out of scope of Reproducible Builds: if Gradle .module absolutely wants to contain javadoc hash, .module will have to be out of scope too

[gredler]

Interesting! Is the JavaDoc JAR file not compared during verification? I don't see it listed in okFiles or in koFiles. I assume it was legitimately different, which would be why the .module file lists different hashes for it.

As to why it might have been different, the only thing I can think of is if slightly different Java versions are generating slightly different JavaDoc output. Have you seen this happen before?

Regarding the Gradle build documentation, where in the docs would be the best place to look to add a few improvements?

[hboutemy]

look at the last line of every report: "(size is calculated without javadoc, that has been excluded from reproducibility checks)"

[gredler]

Thanks, I had missed that. Is that a pragmatic choice (e.g. because different Java minor releases change the JavaDoc output so much that it is hard to reproduce reliably), or a principled choice (e.g. because JavaDoc output is considered out of scope regardless of the implementation difficulty or ease)?

Where should I look to contribute Gradle configuration documentation? Is this page (https://reproducible-builds.org/docs/jvm/) generated from this Markdown (https://github.com/prototypefund/reproducible-website/blob/master/_docs/jvm.md)? They seem similar, but not quite in sync.

Or would this file (https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/doc/TOOLS.md) be better?

[hboutemy]

at the very beginning, it was a pure pragmatic choice based on the low value from knowing that java doc could be reproduced as source and binary: I knew that javadoc was not meant to be stable over time because it often depends on external site urls providing external javadoc to create link, then it was not unexpected when a javadoc site disappears that javadoc won't render the same was (and I don't want to try to inject mocks at that level: too complex, I had sufficient work for source and binaries).
And since then, I learned that in addition javadoc has variations at JDK minor versions level (particularly for embedded JavaScript), which make it very unpractical to create equivalent rebuild environment.
I still consider nowadays that ignoring is a good tradeoff

[hboutemy]

modifying https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/doc/TOOLS.md looks a good choice

[gredler]

OK, thanks! I'll have a look at TOOLS.md.

Since JavaDoc JARs are flaky and excluded, then the Gradle .module file needs to either be partially or completely ignored. Most of the important information in that file is already being checked (explicitly or implicitly) by checking the other files, so it's probably not a great loss to exclude it completely. Would this be a change here? Should I open an issue, or were you thinking about going in a different direction?

[hboutemy]

are you able to work on open-telemetry/opentelemetry-java#4488? it would be nice :)

[hboutemy]

on .module, I don't know how, but some projects produce such files which are reproducible: I'd love top avoid ignoring them by default, and have the ignore flag only when necessary

[DPUkyle]

Since JavaDoc JARs are flaky and excluded, then the Gradle .module file needs to either be partially or completely ignored.

Hi @gredler. Can you share the diff you're seeing in the .module files (a.k.a. Gradle Module Metadata)? Is it specifically the embedded checksums for the javadoc jars?

[DPUkyle]

are you able to work on open-telemetry/opentelemetry-java#4488? it would be nice :)

I will have a look at this!

[hboutemy]

Can you share the diff you're seeing in the .module files

oh, I forgot to configure the link to diffoscope files in https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/uk/org/okapibarcode/okapibarcode/README.md : they'll appear tonight

here is one, for example https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/uk/org/okapibarcode/okapibarcode/okapibarcode-0.4.6.diffoscope