Le dimanche 29 septembre 2019, 21:31:58 CEST Emmanuel Bourg a écrit :
> Le 29/09/2019 à 20:46, Hervé BOUTEMY a écrit :
> > This is exactly how I see Reproducible Builds for the future:
> > - select versions of plugins that bring reproducible output
> > - either inherit or define a local timestamp
While default stays not reproducible (keep in mind we enrich with dated
timestamp or build user metadata in jar quite commonly and i dont think we
want to sed/drop it) and reproducible mode gets an explicit flag in plugins
it sounds very promishing to me, in particular for containers case.
Le
Le 29/09/2019 à 20:46, Hervé BOUTEMY a écrit :
> This is exactly how I see Reproducible Builds for the future:
> - select versions of plugins that bring reproducible output
> - either inherit or define a local timestamp
>
> et voilà, it's so easy (once plugins support)...
How do you plan to
Let's not talk about technologies but talk about the use case because the
use case will uncover the purpose what target is in the background of this
request.
Romain, an therefore i was not firstly talking about concret SCM, but
Harald, and it means the SCM can be one of the implementations -
Hunter wrote:
What if that timestamp was based upon the scm's last commit timestamp
> instead of the time of the build?
>
Folks: remember that Subversion works differently to Git. With subversion
there's no hash, just an integer that goes up constantly for everything in
the larger repo. Your
perhaps I should basically show how Reproducible Builds was configured in the
PoC:
1. in apache-parent:
https://github.com/apache/maven-apache-parent/commit/d379a72d07173c500be65fd6e549da1fedb46b5f
It's about 3 packaging plugins that have a version supporting Reproducible
Builds
and one
scm does not work cause one common use case is to rebuild from source the
same artifacts (debian rebuild from source AFAIK, even java apps)
since scm can be "proxied", copied etc then the source can differ and
therefore commits can be differents but the content can be the same
this is why jib uses
yes Hunter, exactly this was one possibility.
The names of the property can be just like in the HTTP Headers:
Last-Modified
If-Modified-Since -> maybe here can be also the commit hash, not only time
in millis/UTC
ETag
and every module may have different value ;-) then. and then the SCM... has
to
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
wrote:
Can somebody explain a realistic USE CASE when you trigger two consequent
builds (with no changes in
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
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 (
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
Le dimanche 29 septembre 2019, 16:31:35 CEST Robert Scholte a écrit :
> On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli
>
> wrote:
> > Il dom 29 set 2019, 12:16 Robert Scholte ha
> >
> > scritto:
> >> I would think that all project.* properties represent the pom.xml and
> >> are
> >>
Le dimanche 29 septembre 2019, 12:41:17 CEST Enrico Olivelli a écrit :
> Il dom 29 set 2019, 12:16 Robert Scholte 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
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
Le dimanche 29 septembre 2019, 16:54:04 CEST Emmanuel Bourg a écrit :
> Le 28/09/2019 à 17:55, Hervé BOUTEMY a écrit :
> > 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
Le 28/09/2019 à 17:55, Hervé BOUTEMY a écrit :
> 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
On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli
wrote:
Il dom 29 set 2019, 12:16 Robert Scholte 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.
Il dom 29 set 2019, 12:16 Robert Scholte 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?
>
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
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?
Robert
On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY
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
very good question: this was a key question to me, that lead me to the PoC to
test and see
this PoC showed a basic fact: a POM will inherit the value from his parent
Then once a parent POM has a "reproducibility" timestamp, child POMs inherit
reproducible configuration, and can eventually
Hervé
When will you set this value? During release:prepare and modify the pom?
Enrico
Il sab 28 set 2019, 17:55 Hervé BOUTEMY ha scritto:
> Achieving Reproducible Builds require only one parameter: plugins that
> create
> zip or tar archives require a fixed timestamp for entries
>
> Putting
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
25 matches
Mail list logo
