fpapon commented on pull request #313: URL: https://github.com/apache/shiro/pull/313#issuecomment-882783784
> 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](https://repository.apache.org/service/local/repositories/releases/archive/org/apache/shiro/shiro-core/1.7.1/shiro-core-1.7.1.jar/!/META-INF/MANIFEST.MF)) > > 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`](https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions) 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](https://repository.apache.org/service/local/repositories/releases/archive/org/apache/shiro/shiro-core/1.7.1/shiro-core-1.7.1.jar/!/META-INF/MANIFEST.MF)) > > > 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`](https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions) 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
