fix Reproducible Builds issues introduced during release process

[hboutemy]

Environment Details

• GlassFish Version (and build number): 7.0.9

---

Problem Description

release binaries cannot be reproduced: see https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/glassfish/main/README.md

Steps to reproduce

if you want to rebuild, you can clone https://github.com/jvm-repo-rebuild/reproducible-central and run

./rebuild.sh content/org/glassfish/main/glassfish-7.0.9.buildspec

Impact of Issue

• cannot get the same binaries
• current binaries are inconsistent: module info of 7.0.9 release contains 7.0.9-SNAPSHOT version

how to solve

1. in the release script run by https://ci.eclipse.org/glassfish/view/GlassFish/job/glassfish_1-build-and-stage/ , in the second phase, clean before deploy:

mvn -B -U -q -Poss-release,release-phase2 -DskipTests -Ddoclint=none -DstagingProfileId=1c0c18a0fc339 -Dmaven.javadoc.failOnError=false deploy

s/deploy/clean deploy/

2. release hk2 3.0.5 that includes https://github.com/eclipse-ee4j/glassfish-hk2/pull/821 and upgrade in Glassfish

3. eventually, in the release script, when cloning the Git repository, remove the setguid bit that brings unusual permissions

With these 3 steps done, next release should be near fully reproducible (we'll probably find a few remaining issues, given the size of the build)

[arjantijms]

Thanks for the issue! HK2 3.0.5 is long overdue. I'll take a look at releasing it soon. I'll take a look at the release script as well.

[hboutemy]

Hi @arjantijms , IIUC, next Glassfish release is happening soon: can you make sure that the release scripts have been updated, please? This is what is causing the most issues Of course, HK2 3.0.5 release and use in Glassfish would also be great, but to me, release script is first priority

[arjantijms]

Of course, HK2 3.0.5 release and use in Glassfish would also be great, but to me, release script is first priority

HK2 3.0.5 has been released and will be used in the next release of GF (7.0.10):

https://repo1.maven.org/maven2/org/glassfish/hk2/hk2-bom/3.0.5/

[arjantijms]

in the second phase, clean before deploy:

This was done a while ago, it's now:

 mvn -B -U -q -Poss-release,release-phase2 ${MVN_STAGING} \
     -DskipTests -Ddoclint=none -Dmaven.javadoc.failOnError=false \
     -DstagingProfileId=1c0c18a0fc339 \
     clean deploy

[hboutemy]

FYI, HK2 3.0.5 release itself is reproducible https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/glassfish/hk2/README.md (README will be updated in 24h) you'll see in the buildspec that I had to tweak directory permissions to add setgid flag, which is not ideal, but works

[github-actions[bot]]

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment

[dmatej]

@hboutemy Hi, seems you checked the 7.1.0-M1, can you try also 8.0.0-M13? I am not sure if I should create a PR to your repository or how to do that.

[hboutemy]

issues from 7.0.9 have been solved for a long time now since 7.0.16, remaining issues are described in https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/glassfish/main/glassfish-main-aggregator-8.0.0-JDK17-M12.diffoscope

given the scope, I chose to ignore those in 7.0.22 and more

do yu think there is a chance you change the approach with sample generated keystore etc... described in https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/glassfish/main/glassfish-main-aggregator-8.0.0-JDK17-M12.diffoscope ? I was thinking at doing the same ignores for 8.0.0-M13

[hboutemy]

rebuild of 8.0.0-M13 started without ignores, to see if we have the same classical 11 issues with same diffoscope

https://github.com/jvm-repo-rebuild/reproducible-central/pull/3975

[dmatej]

We don't plan to release 8.0.0-JDK17-M13, the only reason for JDK17 version was a need to validate the TCK for Jakarta EE 11.

Keystores ... hmm. Honestly I don't like we do release anything with compromised private key at all, so we recommend users to create a new domain and keep this just for demonstrative purposes.

But maybe there could be yet another option, generating all these files on the first start-domain. I am not sure about consequences for the TCK, as some tests copy certificates before execution ... This would resolve both issues, reproducible builds and compromised keystores in one step.

I can try to create some prototype branch and run the TCK as it is to see if there is some pain waiting behind the corner.

[hboutemy]

grrrrr, plugins are causing confusion to auto-detection of not-deployed Maven modules:

[INFO] Installing Nexus Staging features:
[INFO]   ... total of 310 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] Inspecting build with total of 310 modules
[INFO] Installing Central Publishing features

I'll need to rework the build parameters and/or the artifact:compare goal

I can try to create some prototype branch and run the TCK as it is to see if there is some pain waiting behind the corner.

that would be great

[hboutemy]

rebuilding with deploy skip auto-detection disabled: we'll see... https://github.com/jvm-repo-rebuild/reproducible-central/pull/3975

[dmatej]

I hope Eclipse will soon release the parent pom 2.0.0, so the nexus staging plugin will go away.

[hboutemy]

yes the fact is that, if we ignore the modules not available in Maven Central (easy = those with "wget" approach to do manual research), we have the expected 11 not reproducible artifacts

and associated diffoscope https://github.com/jvm-repo-rebuild/reproducible-central/actions/runs/18367773616

your prototype branch to test new approach to the first start domain is definitively the best bet