Le jeudi 10 octobre 2019 17:17:07 CEST, vous avez écrit :
> Hi Hervé,
>
> >> - We already have maven.build.timestamp [1], so I wonder whether it
> >> should be maven.build.outputTimestap, too. Although one may argue that
> >> this *output* timestamp is a property of the project being built, not
> >> the Maven execution (in particular if the property becomes a POM element
> >> in POM version 5).
> >
> > you got it: it's project.* because it will be a POM element in POM v5
>
> Makes sense. Actually, my interpretation of the maven.* prefix (as being
> for the execution itself) seems to be wrong: A lot of core
> maven-*-plugins use this prefix for their properties, e.g.,
> maven.clean.failOnError, maven.install.skip, or maven.jar.forceCreation.
>
> Anyway, project.* makes more sense.
>
> >> Unfortunately, SimpleDateFormat or its java.time equivalents do not seem
> >> to have a format string for "seconds since the epoch", so we may want to
> >> make "seconds since the epoch" the default for
> >> project.build.outputTimestamp's format and only parse according to
> >> project.build.outputTimestamp.format when that property is indeed set.
> >>
> >> WDYT?
> >
> > the parsing from String to Date is done in maven-archiver code [1], then
> > we
> > can have the algorithm we want. We can even code that if the value is only
> > digits, it's parsed as "seconds since the epoch": no need to add the
> > format
> > property, the choice on one format over the other would be based on
> > effective value
>
> Yes, all digits -> "seconds since epoch" would be a reasonable heuristic.
>
> > What I don't get is: why do you absolutely want such a format?
> > And why do you want to use ${env.SOURCE_DATE_EPOCH}?
> > The proposal is about having "native" Reproducible Builds for Maven, then
> > not something added by an external rebuilder: it will be configured by
> > the original release.
>
> OK, I think I have misunderstood your use case:
>
> In the make-style builds I know that use SOURCE_DATE_EPOCH, some build
> step typically extracts a commit timestamp from, say, git and then sets
> SOURCE_DATE_EPOCH. This variable is then read and interpreted by the
> various built steps that follow. In other words, SOURCE_DATE_EPOCH is
> fed into the build from the outside.
>
> You seem to envision project.build.outputTimestamp to be hard-coded in
> the (consumer?) POM, i.e., not added from the outside (e.g., via
> ${env.SOURCE_DATE_EPOCH}). Is this interpretation correct?
yes
the only little mis-interpretation is that it is a pure build information,
then I don't see why this property would appear in a consumer POM
you can test it by building the fully working PoC:
https://github.com/apache/maven/tree/reproducible
>
> This means that updating the value would fall, e.g., to the
> maven-release-plugin (via [1]), so only releases would have a
> project.build.outputTimestamp (matching the release's time, not the
> timestamp of the corresponding commit, I assume).
the release plugin will update the release timestamp, yes.
But SNAPSHOTs would also have a timestamp just because they kept the timestamp
of previous release or they inherited from parent
>
> I would prefer if each commit would get an output timestamp matching the
> commit timestamp. Maybe one can use the buildnumber-maven-plugin [1] to
> achieve this, though. Setting <timestampPropertyName> to
> project.build.outputTimestamp would initialize that property during the
> "initialize" phase. Would that be early enough to be picked up by rest
> of the build.
imagine the commit is about a unit test, or documentation: changing the
timestamp would change the jar that has exactly the same .class content.
I think that updating the timestamp on every commit for SNAPSHOTs can seem
logical, but finally it would be counter-productive: that would break one
benefit of Reproducible Builds we can have for SNAPSHOTS is that we can use jar
hash to know if the code has changed or not = one use case that someone was
interested in when I had discussions with people (not on mailing list)
>
> Also, would a property set this way be part of the consumer POM?
I see this data only useful at build time: I don't know why it could be useful
at consume time
>
> I hope you can see what I am getting at, even if I might not have
> explained it very well.
I understand your solutions that look reasonably feasible, but not really
their objective.
But I appreciate the concrete discussion: maybe you have a use case that was
not defined before
Regards,
Hervé
>
> Best wishes,
>
> Andreas
>
> [1] <<https://issues.apache.org/jira/browse/MRELEASE-1029>
> [2] <https://www.mojohaus.org/buildnumber-maven-plugin/create-mojo.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
