What if that timestamp was based upon the scm's last commit timestamp instead
of the time of the build?
Hunter
On Sunday, September 29, 2019, 10:25:41 AM PDT, Tibor Digana
<tibordig...@apache.org> wrote:
Can somebody explain a realistic USE CASE when you trigger two consequent
builds (with no changes in sources) and that you expect identical MD5 of
the build artifacts (JAR)?
This can be achieved only when the "timeStamp" in properties is fixed
unmodified in POM.
Does it make sense to call it timeStamp if it is not related to build time
nothing but some kind of , well I don't know what time because the time is
incremental and does not stop.
Even not very pragmatic to control it because you as USER have to correlate
MD5 with the algorith which produces the timeStamp and its changes.
If no MD5 has changed, the timeStamp would not change either. And here is
the problem: what if this rule is broken? And another problem: how you want
to ensure that the timeStamp is changed if and only if the changes have
been done. Somehow connected to the previous discussion with the
Incremental Build.
On Sun, Sep 29, 2019 at 5:55 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> Hi all,
>
> Wonder if it can't "just" (this is not a small task but in terms of design
> it is small ;)) be a flag on higher level archiver plugins
> (maven-jar-plugin being the first one we'll all have in mind).
> I take as a reference jib here which takes into account a creation time for
> that case (
>
> https://github.com/GoogleContainerTools/jib/blob/master/jib-maven-plugin/src/main/java/com/google/cloud/tools/jib/maven/JibPluginConfiguration.java#L190
> ).
> Long story short, they have ~3 modes:
>
> 1. set epoch + 1s (there are issue setting epoch directly)
> 2. set a constant time configured by the user
> 3. respect file time (not reproducible but enable to disable it)
>
> At the end it means we don't need a project.build.* property but just to
> enrich plugins (maybe let's start with jar one) to handle that.
>
> I also wonder if I'm too biased on the topic but if I would have to work on
> it now with our current ecosystem, I would "just" (again ;)) use
> maven-shade-plugin and a set of transformers to handle all files which can
> have not deterministic changes.
> This enables to get the feature immediately without anything specific in
> maven core and handle even external plugin generated files through external
> transformers - a real reproducible build feature would need this extension
> anyway, think about frontend resources included in META-INF/resources for
> example.
> Only missing piece in shade plugin is the Jar reproducibility handling but
> this is likely very doable since we already have JarOutputStream impl at
> apache which can host it IMHO.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 29 sept. 2019 à 17:45, Hervé BOUTEMY <herve.bout...@free.fr> a
> écrit :
>
> > Le dimanche 29 septembre 2019, 12:29:47 CEST Karl Heinz Marbaise a écrit
> :
> > > Hi Hervé,
> > >
> > > On 29.09.19 11:19, Hervé BOUTEMY 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?
> > >
> > > This sounds like the best idea...
> > >
> > >
> > > This would mean to define something like this:
> > >
> > > <properties>
> > > <project.build.timestamp>..</project.build.timestamp>
> > > </properties>
> > >
> > > But now there are coming up some questions:
> > >
> > > * Is that the real value to be used?
> > > * Or should it activate the mechanism ? (boolean?)
> > we can define both a boolean and a timestamp
> > but the timestamp de-facto means also a boolean: defined means true,
> > undefined
> > means false
> >
> > >
> > > <properties>
> > > <project.build.timestamp.usage>true</project.build.timestamp.usage>
> > > </properties>
> > >
> > >
> > > * Or should we use it by default and giving the user the opportunity
> > > to overrite the current timestamp by fixed timestamp for building ?
> > > This means we would define only the real time to be used during
> > > building. No need for a kind of activation etc.
> > > So you could call Maven via:
> > >
> > > mvn -Dproject.build.timestamp=... package
> > >
> > >
> > > * Or do we need a combination of the above
> > >
> > > First activate, define the format and the timestamp to be used.
> > >
> > >
> > > Furthermore do we need to define a format either which could look like
> > this:
> > >
> > > <properties>
> > > <project.build.timestamp.usage>true</project.build.timestamp.usage>
> > > <project.build.timestamp>..</project.build.timestamp>
> > >
> > <project.build.timestamp.format>ISO-8601</project.build.timestamp.format>
> > > </properties>
> > letting the format as a third parameter is of course feasible, but adds
> > complexity: is it really necessary? Isn't ISO-8601 sufficient to you?
> >
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > > 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
> >
> >
>
