Le dimanche 29 septembre 2019, 12:16:48 CEST Robert Scholte a écrit :
> 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.
+1

> Instead this seems more related the (maven)session, right?
no
It has to be reproducible from build to build = that's the objective.
That's why a value has to be recorded, whatever the exact value is.
A consequence is that the value won't be the effective build time, since it has 
to be the same value next month, next year, or next century.
It has to be recorded one day, then stay for posterity.

Ideally, it will be recorded during a release process: that's why I imagine 
that we'll have maven-release-plugin do an automated update.
But it can stay to a point in time: who cares of the exact value? As I already 
said, to avoid a debate, some Reproducible Builds solutions just use 
1970-01-01T00:00:00Z as timestamp: basic, but it works

Regards,

Hervé

> 
> 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

Reply via email to