-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