Le vendredi 11 octobre 2019, 10:03:10 CEST Christofer Dutz a écrit : > Hi Enrico, > > so I would definitely +1 to be able to do it this way ... > I think reproducible builds are important for releases, but I am not that > sure the same applies for the daily business in a project. For being able > to do releases it would be a huge improvement, if this is automatically > handled the same way the versions are updated. see https://issues.apache.org/jira/browse/MRELEASE-1029
> For the plc4x project I was even thinking of building some maven tooling to > automatically verify the built archives with the ones staged in nexus for > binary equality. yes, that's a next step: I see we have the same idea :) At the moment, this is what I expect from Buildinfo file proposal we wrote (with a sbt developer, since that proposal is globally JVM-oriented, whatever the build tool is): https://reproducible-builds.org/docs/jvm/ If the release manager publishes the buildinfo of his "reference" release build (= 1 buildinfo, even if there are thousands of artifacts), it could be easily compared to a rebuilder's buildinfo done during his local rebuild. One year ago, I was ready to write a Maven plugin for generating such buildinfo, when I thought that starting from this plugin would not bring real value until we had a chance to get reproducible results. Now that native Reproducible Builds for Maven is near, writing the plugin that will generate a buildinfo file makes sense and should not be really complex (less complex than MRELEASE-1029 , for example) For those interested in Reproducible Builds, next yearly meeting is in december https://reproducible-builds.org/events/ Last year event in Paris was key to my understanding of so many aspects we'll need to manage in future years to get the full value of Reproducible Builds in Java Of course, we can also work on this during Apache Conference Europe 2019 https://aceu19.apachecon.com/ I hope to meet a lot of people and discuss a lot of good steps forward Regards, Hervé > Chris > > Am 11.10.19, 09:05 schrieb "Enrico Olivelli" <[email protected]>: > > Il ven 11 ott 2019, 08:31 Christofer Dutz <[email protected]> > ha scritto: > > > > Just a small question. I have been following this thread with great > > interest. > > > > > > > > I think this is going to be a big thing when it makes the changes > > available to the main maven system. > > > > > > > > So as far as I understand the core part will be a fixed timestamp > > which > > will then be used throughout the build by multiple pluggins. > > > > > > > > So if I provide the same timestamp the result should be binary > > identical. > > > > > > > > Would it be possible to have this timestamp written/updated in the pom > > as > > part of the release:prepare step? > > > > > > > Yep, this was one of my questions at the beginning of this thread. > I see value in this proposal > > Enrico > > > > > > > Sort of setting it to some constant (ie REPODUCEABLE_BUILD_TIMESTAMP) > > simply takes the current time but if there is a concrete value, it > > uses > > that instead? > > > > > > > > Hope im not asking anything obvious. To me it looked as if the > > timestamp > > has to be manipulated manually. > > > > > > > > Chris > > > > > > > > Holen Sie sich Outlook für Android<https://aka.ms/ghei36> > > ________________________________ > > From: Emmanuel Bourg <[email protected]> > > Sent: Thursday, October 10, 2019 11:50:34 PM > > To: [email protected] <[email protected]> > > Subject: Re: last review of Reproducible Builds proposal > > > > > > > > Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit : > > > > > > > > > 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 > > > > > > > > Thank you for the clarification, that makes perfectly sense. And I > > now > > see the benefit of using a property that can be inherited. In a multi > > modules project it's only necessary to define the timestamp once in > > the > > root pom. Parent poms deployed to Maven Central will never include a > > timestamp and there is no risk of affecting other projects deriving > > from > > the pom. > > > > > > > > Emmanuel Bourg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
