gnodet commented on PR #1726: URL: https://github.com/apache/maven/pull/1726#issuecomment-2373078384
> > I guess that whether they could be set to the timestamp of the source files or git commit has already been discussed then. > > * source file: not really discussed, as it is complex (think about generated files, synthetic inner classes, ...). Add to that that timestamp on disk is not predictible when you Git clone or checkout, or svn checkout, or any other source control > * git commit: yes, but 1. not everything is built from Git, 2. it kills build cache > > > download the real jar first and then extract the used timestamp value from there, then inject it into the reproducible build > > quite works, but complex and does not give one simple workflow: as a developer, I want to build my source code twice and get the same output (which will also help build-cache) > > I don't see how we can be less basic than a fixed timestamp by default in Maven core: perhaps a less strange default value could lower bad feelings about it, something like `2024-01-01 00:00:00`? It's up to any project to override to a value that makes more sense to it: if a project chooses to really be tied to Git, they can choose to use last Git commit timestamp, taht's their choice (IMHO, not the best one because of build cache, but I let everybody do their local choices) Yes, I think this would be more obvious, but why not `2001-01-01 00:00:00` then (beginning of 21st century) ? Another possibility would be to add that only to the 4.1.0 root pom, and add a warning if not defined. However, it would be nice if the release plugin could automatically (with opt-out) _create_ the property in the root pom instead of only _updating_ it. -- 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...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
