Le dimanche 29 septembre 2019, 12:41:17 CEST Enrico Olivelli a écrit :
> 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
which session? since there will be new sessions every now and then, when
someone builds
> - 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'
IMHO, not *must* but *can* or *should*: it it stays at a past timestamp, there
won't be any big harm.
But if it can be the timestamp of the release process, it can be better for
people who look at zip entries timestamp (if anybody looks at it: do you look
at it?)
Regards,
Hervé
>
>
> 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
