Upgrade to Apache pom 24 and make build reproductible

[fpapon]

No description provided.

[bmarwell]

Nit

[bdemers]

I'm a little confused, and I haven't been following the history of the project.build.outputTimestamp property. So I'm going to make some guesses and assumptions (I could be miss remembering, or referencing topics not relevant to this PR, if so just ignore me 🤣)

project.build.outputTimestamp is used so that multiple builds from the same source will produce identical binaries (same checksums, etc). (likely this gets deeper into trust as well). There are a bunch of other small problems related to this. One source is the MANIFEST (which contains the name of the builder and which JVM was used, the 1.7.1 build example)

Setting the value to 1 disables this feature:
https://github.com/apache/maven-release/blob/a9e30c63ea8071234e9a7bb1f433178963ecf93c/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L350-L375

Ideally, we remove all timestamps from the build's output, but either way, until we resolve the other issues we probably want to keep things simple and disable it (rather than having changing timestamp in the pom and the potential merge conflicts that could add)? (maybe these have already been worked in plugin updates, and bumping the parent fixes most/all of that?)

That said, I'm +0 on the change.

[fpapon]

I'm a little confused, and I haven't been following the history of the project.build.outputTimestamp property. So I'm going to make some guesses and assumptions (I could be miss remembering, or referencing topics not relevant to this PR, if so just ignore me rofl)

project.build.outputTimestamp is used so that multiple builds from the same source will produce identical binaries (same checksums, etc). (likely this gets deeper into trust as well). There are a bunch of other small problems related to this. One source is the MANIFEST (which contains the name of the builder and which JVM was used, the 1.7.1 build example)

Setting the value to 1 disables this feature:
https://github.com/apache/maven-release/blob/a9e30c63ea8071234e9a7bb1f433178963ecf93c/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L350-L375

Ideally, we remove all timestamps from the build's output, but either way, until we resolve the other issues we probably want to keep things simple and disable it (rather than having changing timestamp in the pom and the potential merge conflicts that could add)? (maybe these have already been worked in plugin updates, and bumping the parent fixes most/all of that?)

That said, I'm +0 on the change.

I didn't go deeper on reproductible build and this is related to the changes in the new apache pom parent which has a maven profile with an enforce rule about this property.

[bmarwell]

I'm a little confused, and I haven't been following the history of the project.build.outputTimestamp property. So I'm going to make some guesses and assumptions (I could be miss remembering, or referencing topics not relevant to this PR, if so just ignore me rofl)
project.build.outputTimestamp is used so that multiple builds from the same source will produce identical binaries (same checksums, etc). (likely this gets deeper into trust as well). There are a bunch of other small problems related to this. One source is the MANIFEST (which contains the name of the builder and which JVM was used, the 1.7.1 build example)
Setting the value to 1 disables this feature:
https://github.com/apache/maven-release/blob/a9e30c63ea8071234e9a7bb1f433178963ecf93c/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L350-L375
Ideally, we remove all timestamps from the build's output, but either way, until we resolve the other issues we probably want to keep things simple and disable it (rather than having changing timestamp in the pom and the potential merge conflicts that could add)? (maybe these have already been worked in plugin updates, and bumping the parent fixes most/all of that?)
That said, I'm +0 on the change.

I didn't go deeper on reproductible build and this is related to the changes in the new apache pom parent which has a maven profile with an enforce rule about this property.

Maybe we can go step by step? I would be okay with this change if we only started an epic "reproducible builds" here.
See https://repository.apache.org/service/local/repositories/releases/archive/org/apache/maven/maven-core/3.8.1/maven-core-3.8.1.jar/!/META-INF/MANIFEST.MF for example. They have way less information in their files.

[fpapon]

I'm a little confused, and I haven't been following the history of the project.build.outputTimestamp property. So I'm going to make some guesses and assumptions (I could be miss remembering, or referencing topics not relevant to this PR, if so just ignore me rofl)

project.build.outputTimestamp is used so that multiple builds from the same source will produce identical binaries (same checksums, etc). (likely this gets deeper into trust as well). There are a bunch of other small problems related to this. One source is the MANIFEST (which contains the name of the builder and which JVM was used, the 1.7.1 build example)

Setting the value to 1 disables this feature:
https://github.com/apache/maven-release/blob/a9e30c63ea8071234e9a7bb1f433178963ecf93c/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L350-L375

Ideally, we remove all timestamps from the build's output, but either way, until we resolve the other issues we probably want to keep things simple and disable it (rather than having changing timestamp in the pom and the potential merge conflicts that could add)? (maybe these have already been worked in plugin updates, and bumping the parent fixes most/all of that?)

That said, I'm +0 on the change.

I didn't go deeper on reproductible build and this is related to the changes in the new apache pom parent which has a maven profile with an enforce rule about this property.

I'm a little confused, and I haven't been following the history of the project.build.outputTimestamp property. So I'm going to make some guesses and assumptions (I could be miss remembering, or referencing topics not relevant to this PR, if so just ignore me rofl)
project.build.outputTimestamp is used so that multiple builds from the same source will produce identical binaries (same checksums, etc). (likely this gets deeper into trust as well). There are a bunch of other small problems related to this. One source is the MANIFEST (which contains the name of the builder and which JVM was used, the 1.7.1 build example)
Setting the value to 1 disables this feature:
https://github.com/apache/maven-release/blob/a9e30c63ea8071234e9a7bb1f433178963ecf93c/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L350-L375
Ideally, we remove all timestamps from the build's output, but either way, until we resolve the other issues we probably want to keep things simple and disable it (rather than having changing timestamp in the pom and the potential merge conflicts that could add)? (maybe these have already been worked in plugin updates, and bumping the parent fixes most/all of that?)
That said, I'm +0 on the change.

I didn't go deeper on reproductible build and this is related to the changes in the new apache pom parent which has a maven profile with an enforce rule about this property.

Maybe we can go step by step? I would be okay with this change if we only started an epic "reproducible builds" here.
See https://repository.apache.org/service/local/repositories/releases/archive/org/apache/maven/maven-core/3.8.1/maven-core-3.8.1.jar/!/META-INF/MANIFEST.MF for example. They have way less information in their files.

They have less information in the MANIFEST.MF because it's not a bundle, so they don't have OSGi metadata.

[bdemers]

Ahh, that Maven manifest does look a lot better! 😄

[fpapon]

@bdemers @bmarwell I merged the PR for reproductible build thanks to @hboutemy

[bdemers]

@fpapon Nice!!

[bmarwell]

LGTM. I just wonder: will the username still be in the META-INF/MAINFEST.MF files? But we can check afterwards.