Le dimanche 29 septembre 2019, 16:31:35 CEST Robert Scholte a écrit : > On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli <eolive...@gmail.com> > > wrote: > > Il dom 29 set 2019, 12:16 Robert Scholte <rfscho...@apache.org> ha > > > > scritto: > >> I would think that all project.* properties represent the pom.xml and > >> are > >> immutable. To be more precise: the same pom.xml should effectively stay > >> the same with every build. > >> Instead this seems more related the (maven)session, right? > > > > If I understand correctly the value f this property is to be committed in > > the source code. > > Some thoughts: > > - it should default to 'now' sampled at the beginning of the session > > - it can be overridden with a value writen in the pom or on a source file > > - it must be sampled and commited as final value during a 'release > > process' > > There is already a property with a similar name: maven.build.timestamp > We need to keep in mind when thinking of a good name: which one is used > for what? > > Reading the mail again, it looks like it is not about the timestamp of the > build. It is more about setting the lastModified value (and maybe also > created + opened?) of files inside the archive. > I would prefer a name that clearly reflects that. +1 you're right, need to find a better name reproducibleTimestamp? outputTimestamp?
> > I don't like the idea of being able to set a property that starts with > `project.`. > Based on stack overflow people find it sometimes hard to understand, so we > should be very clear about this: > `project.` represents project-roottag of the pom.xml, and with this you > can read any value, but you cannot SET a value. yes, this is the objective of the choice: in the future, when we have Build vs Consumer POM as discussed in parallel, my intent is to add an element to the POM = exactly like we'll do for project.build.sourceEncoding and project.reporting.outputEncoding > > Is this value important for snapshots too? the fact that there is a value is important, not the precise value itself. And if we do care about the value, for SNAPSHOTs, any timestamp from the previous release to the next one may make sense: I imagine the timestamp from the last release would be a perfect value for the whole duration of a SNASPHOT lifecycle > If not, it shouldn't be too > hard to adjust the maven-release-plugin for setting an explicit value. then during the next release, having maven-release-plugin update the value would make sense Regards, Hervé > > Robert > > [1] > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Av > ailable_Variables > > Enrico > > > >> Robert > >> > >> On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY > >> <herve.bout...@free.fr> > >> > >> wrote: > >> > regarding the property name, I had an idea: > >> > > >> > why not do like we already did for ${project.build.sourceEncoding}, > >> > >> ie. > >> > >> > mimic > >> > a future element in pom.xml, in build? > >> > > >> > could be project.build.timestamp? > >> > > >> > Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit : > >> >> Achieving Reproducible Builds require only one parameter: plugins > >> > >> that > >> > >> >> create zip or tar archives require a fixed timestamp for entries > >> >> > >> >> Putting that parameter as a pom property with a well known name and > >> >> value > >> >> format permits to share the configuration between every packaging > >> >> plugin. > >> >> This also has the advantage that child poms will inherit from parent > >> >> value, > >> >> and eventually override. > >> >> > >> >> The question is: *what property name and what value format should we > >> >> keep?* > >> >> > >> >> For the PoC, I chose to extrapolate from a convention from > >> > >> Reproducible > >> > >> >> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH > >> >> environment > >> >> variable, that I transformed into source-date-epoch property name, > >> >> keeping > >> >> the "date + %s" value > >> >> https://reproducible-builds.org/docs/source-date-epoch/ > >> >> > >> >> > >> >> But I feel we can do a more user-readable solution by choosing > >> > >> another > >> > >> >> name > >> >> and format, like "reproducible-build-timestamp" with an ISO-8601 > >> >> combined > >> >> date and time representation > >> >> > >> >> > >> >> WDYT? Any other idea? > >> >> > >> >> Regards, > >> >> > >> >> Hervé > >> >> > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
