desruisseaux commented on code in PR #36:
URL: https://github.com/apache/sis/pull/36#discussion_r1279045448
##########
pom.xml:
##########
@@ -545,6 +545,7 @@
=================================================================== -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+
<project.build.outputTimestamp>2023-07-15T16:42:39Z</project.build.outputTimestamp>
Review Comment:
A proposal to migrate from Maven to Gradle is [on the
table](https://lists.apache.org/thread/xqnydv188cxom22forz3j8bbkbtv8g14) in
order to modularize the project with `module-info.java` files. While Maven has
some JPMS support, taking full advantage of JPMS requires restructuring the
code from _Package Hierarchy_ to _Module Source Hierarchy_, and the latter
would be very difficult to do with Maven. If this migration is accepted, the
fix proposed in this issue would take a different form.
On binary check versus smart tools, the problem of binary check is that it
throws away valuable metadata such as build time and who made the build. While
the metadata seems to be there, they became meaningless if their values are not
anymore what they seem to be. Metadata with false values are worst than no
metadata, because they create a situation where we don't know anymore which
metadata we can trust. In the particular case of this issue, I think that no
timestamp would be better than a timestamp with fixed value. I highly value the
goal of reproductible builds (it would make me feel safer when I deploy
binaries on Maven Central), but I think that an extremist position on
"bit-by-bit" reproducibility is creating other dangers in a world where false
information became a thread as serious as hackers. In French I would said that
bit-by-bit reproducibility is "jeter le bébé avec l'eau du bain".
--
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: issues-unsubscr...@sis.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
