-javax releases are not reproducible

[hboutemy]

see https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/avaje/inject/README.md

non -javax releases are perfectly checked as reproducible: build recipe is quite simple and classical, like jvm-repo-rebuild/reproducible-central#1361

for -javax releases, the timestamp does not correspond as what is in Git, and there are additional .java-e files in -sources.jar that come from nowhere in Git, like jvm-repo-rebuild/reproducible-central#1359

I don't know what is the release process for -javax builds in Maven Central, but it's not what I'd expect = simply start from Git tag, apply ./jakarta-to-javax.sh and rebuild to deploy: is there a deliberate reason? And in that case, how to generate the .java-e files?

[SentryMan]

@rbygrave do you do anything extra for javax releases?

[rbygrave]

there are additional .java-e files in -sources.jar

That's not great. That'll come from the difference between linux vs macOS wrt sed ... we can fix that.

the timestamp does not correspond as what is in Git

Hmmm, not sure why per se but noting that there are not 2 timestamps meaning that in git the timestamp there is from the jakarta release and not the javax one. So it isn't clear to me how that would work in that to me it seems we'd need 2 timestamps with one for Jakarta and one for Javax ... so not sure.

simply start from Git tag, apply ./jakarta-to-javax.sh and rebuild to deploy:

We also need to change the actual maven pom versions

[rbygrave]

Unless you are asking to have a separate git tag for the javax release? ... is that what you are asking?

[hboutemy]

IMHO, we don't need a separate Git tag for javax release: using the non javax tag is perfect, as AFAIK jakarta-to-javax.sh does perfectly update in a reproducible way (once the script has been updated to work on Mac like it works on Linux: sed -i is a pain on that topic...), then no problem on not storing a separate commit and tag for updated result

[rbygrave]

There was some MacOS sed -I use in jakarta-to-javax.sh. That should be fixed now, and now there is a separate macos-jakarta-to-javax.sh for MacOS use.

So need to review this again and see if we still have an issue here or not.

[hboutemy]

good news: I managed to rebuild 11.2-javax and get the same output
see https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/avaje/inject/README.md

still need a few fixes in jakarta-to-javax.sh, as I was forced to add ad-hoc fixes https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/avaje/inject/avaje-inject-11.2-javax.buildspec#L16
= in first sed invocations, you need -E instead of -e (I suppose it's true for the MacOS one too) https://github.com/avaje/avaje-inject/blob/master/macos-jakarta-to-javax.sh#L5

on the timestamp value, I suppose that once teh fix is in Git and the release process is normal, the value for 11.3-javax will exactly be the same as the one for 11.3, isn't it?

[rbygrave]

on the timestamp value, I suppose that once teh fix is in Git and the release process is normal, the value for 11.3-javax will exactly be the same as the one for 11.3, isn't it?

No, it will be a different timestamp. I don't know if there is a way that can be the same. Hmm.