Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
SOURCE_DATE_EPOCH is perfect for Linux distributions, that do their own
distro-specific packages (.rpm, .deb, .apk, ...) from the upstream project by
adding some patches and some packaging instructions
=> having a general way to inject its own choice of timestamp through a
standardized environment variable is perfect (for any language or build tool)
here, we are at upstream project level focusing on the JVM and Maven, trying to
avoid the Java developer to have to run anything additional when he builds his
project, and even less when he's a release manager doing the official release
(with maven-release-plugin or other automation approach)
That's why Maven-way to inject a predictable timestamp is not by adding (by
hand or expecting a shell script) an environment variable before running mvn,
but getting the value calculated inside mvn invocation
but Reproducible Builds principles remain the same: a predictible timestamp is
absolutely necessary to have reproducible timestamp entries in archives (based
on tar & zip in general)
Regards,
Hervé
On 2024/09/25 18:50:08 John Neffenger wrote:
> A follow-up message for those not familiar with the SOURCE_DATE_EPOCH
> environment variable ...
>
> On 9/25/24 9:22 AM, John Neffenger wrote:
> > That makes sense, but in general, I always set the date like this:
> >
> > SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
> > export SOURCE_DATE_EPOCH
> >
> > I pass that to Maven with:
> >
> >
> > ${env.SOURCE_DATE_EPOCH}
> >
>
> The page below describes the variable, including a link to its
> specification:
>
> SOURCE_DATE_EPOCH
> https://reproducible-builds.org/docs/source-date-epoch/
>
> The following page gives more background information:
>
> ReproducibleBuilds/StandardEnvironmentVariables
> https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables
>
> John
>
>
> -
> 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
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
> So just to be clear, what is the really the end goal of enabling it by > default? I know the advantages and benefits, but what would be the goal of > having this opt-out instead of having it opt-in? if you just build without adding any configuration nor any special (or old) plugin, you'll get Reproducible Builds for free = something that I expect to happen for many projects: no need to do anything non-reproducible builds will be caused by some specific plugins (that we'll fix over time as we did until now), or additional config that breaks RB that was there before config this is what good defaults are about Regards, Hervé On 2024/09/25 14:23:52 Jorge Solórzano wrote: > There are some solutions/alternatives here: > > 1) Fixed value by default. > 2) Warning to the user for having reproducible builds off. > 3) Use the SCM last commit date. > > I have worked a tiny bit for the Reproducible Builds effort so here is my 2 > cents: > > * Using the SCM last commit date is a bad choice, not everyone will use SCM > or the source code could be downloaded without scm information (eg.: Source > Code download links from GitHub), so this is a -1 for me. > * Throw a warning to the user to force the set of the project.build > .outputTimestamp value is also a -1 for me, this reminds me of the project. > build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and > having that default value is the correct way to proceed instead of an ugly > warning. > * This leaves us with the fixed value by default, the current value (in the > PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal > preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed. > > There should be a way to opt out of this and get the previous behavior for > those that don't what this. > As fo the release plugin, it should simply use the fixed date (if the > property is not set), having a warning seem ugly the same way as the > sourceEncoding warning was ugly. > > Now, in my experience, sometimes setting the outputTimestamp is not enought > and is not a silver bullet to make a reproducible build. > > So just to be clear, what is the really the end goal of enabling it by > default? I know the advantages and benefits, but what would be the goal of > having this opt-out instead of having it opt-in? > > > > On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : > > >> > > >> For me this looks more like an issue of the jar plugin and should > > >> probably be handled there, then even though I wonder why the zip > > >> entries need a timestamp for a jar to be reproducible, should it not > > >> be enough to compare the zip-entries and leave the timestamp alone? > > >> > > > The idea of a reproducible build is to create binary exact artifacts > > > which you can quickly calculate checksum to compare with some > > > reference build. As the timestamp entry is used in zip/JARs, it > > > changes the binary representation of a jar as well. So yeah, that's > > > important. > > > > > (note: I'm duplicating here a comment I just made on the PR). I guess > > that checksum is not a goal in itself, but the higher level goal is > > security (checking that a JAR file has not been compromised)? If yes, > > then we do not necessarily need bit for bit reproducibility. > > "Semantically reproducible build" or "semantic equivalency" can be as > > good or even better, as it does not force us to throw away useful > > metadata like the real build time. Microsoft has short discussion about > > semantic equivalency there: > > > > https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible > > > > Could the real issue be that we do not have a Maven plugin for making > > semantic equivalency check easy? E.g. a plugin that build a project and > > automatically compare semantically against the JAR file on Maven Central > > or elsewhere? > > > > Martin > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
A follow-up message for those not familiar with the SOURCE_DATE_EPOCH
environment variable ...
On 9/25/24 9:22 AM, John Neffenger wrote:
That makes sense, but in general, I always set the date like this:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH
I pass that to Maven with:
${env.SOURCE_DATE_EPOCH}
The page below describes the variable, including a link to its
specification:
SOURCE_DATE_EPOCH
https://reproducible-builds.org/docs/source-date-epoch/
The following page gives more background information:
ReproducibleBuilds/StandardEnvironmentVariables
https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables
John
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
On 9/25/24 7:23 AM, Jorge Solórzano wrote:
* Using the SCM last commit date is a bad choice, not everyone will use SCM
or the source code could be downloaded without scm information (eg.: Source
Code download links from GitHub), so this is a -1 for me.
That makes sense, but in general, I always set the date like this:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH
I pass that to Maven with:
${env.SOURCE_DATE_EPOCH}
* This leaves us with the fixed value by default, the current value (in the
PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal
preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed.
Right! See my comment below on the pull request that added this feature
to the 'jar' and 'jmod' tools in the JDK:
https://github.com/openjdk/jdk/pull/6481#issuecomment-984220137
Just for reference, at the time of my comment, Debian added 12 hours 1
minute to the first second of 1980 for their default value
(1980-01-01T12:01:00Z), while Gradle skipped to the next month
(1980-02-01T00:00:00Z).
The main thing is to avoid 1980-01-01T00:00:00Z, 1980-01-01T00:00:01Z,
and any earlier instant.
There should be a way to opt out of this and get the previous behavior for
those that don't what this.
How about just using SOURCE_DATE_EPOCH directly when defined? I guess
that's more opt-in than opt-out, but it would at least let me avoid
having to define 'project.build.outputTimestamp' in all my projects.
John
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Hi. if web-download cache be in part of your, Reproducible Builds? Jorge Solórzano 于2024年9月25日周三 22:26写道： > There are some solutions/alternatives here: > > 1) Fixed value by default. > 2) Warning to the user for having reproducible builds off. > 3) Use the SCM last commit date. > > I have worked a tiny bit for the Reproducible Builds effort so here is my 2 > cents: > > * Using the SCM last commit date is a bad choice, not everyone will use SCM > or the source code could be downloaded without scm information (eg.: Source > Code download links from GitHub), so this is a -1 for me. > * Throw a warning to the user to force the set of the project.build > .outputTimestamp value is also a -1 for me, this reminds me of the project. > build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and > having that default value is the correct way to proceed instead of an ugly > warning. > * This leaves us with the fixed value by default, the current value (in the > PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal > preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed. > > There should be a way to opt out of this and get the previous behavior for > those that don't what this. > As fo the release plugin, it should simply use the fixed date (if the > property is not set), having a warning seem ugly the same way as the > sourceEncoding warning was ugly. > > Now, in my experience, sometimes setting the outputTimestamp is not enought > and is not a silver bullet to make a reproducible build. > > So just to be clear, what is the really the end goal of enabling it by > default? I know the advantages and benefits, but what would be the goal of > having this opt-out instead of having it opt-in? > > > > On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : > > >> > > >> For me this looks more like an issue of the jar plugin and should > > >> probably be handled there, then even though I wonder why the zip > > >> entries need a timestamp for a jar to be reproducible, should it not > > >> be enough to compare the zip-entries and leave the timestamp alone? > > >> > > > The idea of a reproducible build is to create binary exact artifacts > > > which you can quickly calculate checksum to compare with some > > > reference build. As the timestamp entry is used in zip/JARs, it > > > changes the binary representation of a jar as well. So yeah, that's > > > important. > > > > > (note: I'm duplicating here a comment I just made on the PR). I guess > > that checksum is not a goal in itself, but the higher level goal is > > security (checking that a JAR file has not been compromised)? If yes, > > then we do not necessarily need bit for bit reproducibility. > > "Semantically reproducible build" or "semantic equivalency" can be as > > good or even better, as it does not force us to throw away useful > > metadata like the real build time. Microsoft has short discussion about > > semantic equivalency there: > > > > https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible > > > > Could the real issue be that we do not have a Maven plugin for making > > semantic equivalency check easy? E.g. a plugin that build a project and > > automatically compare semantically against the JAR file on Maven Central > > or elsewhere? > > > > Martin > > > > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
There are some solutions/alternatives here: 1) Fixed value by default. 2) Warning to the user for having reproducible builds off. 3) Use the SCM last commit date. I have worked a tiny bit for the Reproducible Builds effort so here is my 2 cents: * Using the SCM last commit date is a bad choice, not everyone will use SCM or the source code could be downloaded without scm information (eg.: Source Code download links from GitHub), so this is a -1 for me. * Throw a warning to the user to force the set of the project.build .outputTimestamp value is also a -1 for me, this reminds me of the project. build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and having that default value is the correct way to proceed instead of an ugly warning. * This leaves us with the fixed value by default, the current value (in the PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed. There should be a way to opt out of this and get the previous behavior for those that don't what this. As fo the release plugin, it should simply use the fixed date (if the property is not set), having a warning seem ugly the same way as the sourceEncoding warning was ugly. Now, in my experience, sometimes setting the outputTimestamp is not enought and is not a silver bullet to make a reproducible build. So just to be clear, what is the really the end goal of enabling it by default? I know the advantages and benefits, but what would be the goal of having this opt-out instead of having it opt-in? On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : > >> > >> For me this looks more like an issue of the jar plugin and should > >> probably be handled there, then even though I wonder why the zip > >> entries need a timestamp for a jar to be reproducible, should it not > >> be enough to compare the zip-entries and leave the timestamp alone? > >> > > The idea of a reproducible build is to create binary exact artifacts > > which you can quickly calculate checksum to compare with some > > reference build. As the timestamp entry is used in zip/JARs, it > > changes the binary representation of a jar as well. So yeah, that's > > important. > > > (note: I'm duplicating here a comment I just made on the PR). I guess > that checksum is not a goal in itself, but the higher level goal is > security (checking that a JAR file has not been compromised)? If yes, > then we do not necessarily need bit for bit reproducibility. > "Semantically reproducible build" or "semantic equivalency" can be as > good or even better, as it does not force us to throw away useful > metadata like the real build time. Microsoft has short discussion about > semantic equivalency there: > > https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible > > Could the real issue be that we do not have a Maven plugin for making > semantic equivalency check easy? E.g. a plugin that build a project and > automatically compare semantically against the JAR file on Maven Central > or elsewhere? > > Martin > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : For me this looks more like an issue of the jar plugin and should probably be handled there, then even though I wonder why the zip entries need a timestamp for a jar to be reproducible, should it not be enough to compare the zip-entries and leave the timestamp alone? The idea of a reproducible build is to create binary exact artifacts which you can quickly calculate checksum to compare with some reference build. As the timestamp entry is used in zip/JARs, it changes the binary representation of a jar as well. So yeah, that's important. (note: I'm duplicating here a comment I just made on the PR). I guess that checksum is not a goal in itself, but the higher level goal is security (checking that a JAR file has not been compromised)? If yes, then we do not necessarily need bit for bit reproducibility. "Semantically reproducible build" or "semantic equivalency" can be as good or even better, as it does not force us to throw away useful metadata like the real build time. Microsoft has short discussion about semantic equivalency there: https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible Could the real issue be that we do not have a Maven plugin for making semantic equivalency check easy? E.g. a plugin that build a project and automatically compare semantically against the JAR file on Maven Central or elsewhere? Martin
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Another solution is to migrate to the 4.1.0 Maven model and add the root="true" attribute in the root project pom. The ".mvn" is a way to support both Maven 3 and 4 for a project. Le mer. 25 sept. 2024 à 08:41, Richard Eckart de Castilho a écrit : > > Please do not make us have to create an empty directory just to please > the build tool... > > -- Richard > > > On 24. Sep 2024, at 23:06, Tamás Cservenák wrote: > > > > So, essentially, if you have a Maven3 project, and you want to build it > > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > > already have ".mvn" directory in the proper place. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Ultimatly we could use scm abstraction to use latest commit date, would be almost always ok (except for stale cases and no scm but these cases dont care abojt reproducibility). Can just need a quick impl for git maybe to not penalise builds (direct .git head file read if possible) Le mer. 25 sept. 2024 à 09:05, Delany a écrit : > What about an empty .mvn/maven.config file? > Delany > > On Wed, 25 Sept 2024 at 08:41, Richard Eckart de Castilho > wrote: > > > Please do not make us have to create an empty directory just to please > > the build tool... > > > > -- Richard > > > > > On 24. Sep 2024, at 23:06, Tamás Cservenák > wrote: > > > > > > So, essentially, if you have a Maven3 project, and you want to build it > > > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > > > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > > > already have ".mvn" directory in the proper place. > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
What about an empty .mvn/maven.config file? Delany On Wed, 25 Sept 2024 at 08:41, Richard Eckart de Castilho wrote: > Please do not make us have to create an empty directory just to please > the build tool... > > -- Richard > > > On 24. Sep 2024, at 23:06, Tamás Cservenák wrote: > > > > So, essentially, if you have a Maven3 project, and you want to build it > > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > > already have ".mvn" directory in the proper place. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Please do not make us have to create an empty directory just to please the build tool... -- Richard > On 24. Sep 2024, at 23:06, Tamás Cservenák wrote: > > So, essentially, if you have a Maven3 project, and you want to build it > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > already have ".mvn" directory in the proper place. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
On Wed, Sep 25, 2024 at 5:58 AM Christoph Läubrich wrote: > > yes, this is the idea: there is no other option I can imagine to get > a reproducible zip entries timestamp, whatever the precise value of the > timestamp it is > > If anybody has any other algorithm idea (that supports wide reality > of situation: not everything is built from Git, for example), I'm all > ears open > > For me this looks more like an issue of the jar plugin and should > probably be handled there, then even though I wonder why the zip entries > need a timestamp for a jar to be reproducible, should it not be enough > to compare the zip-entries and leave the timestamp alone? > The idea of a reproducible build is to create binary exact artifacts which you can quickly calculate checksum to compare with some reference build. As the timestamp entry is used in zip/JARs, it changes the binary representation of a jar as well. So yeah, that's important. > > Am 24.09.24 um 22:54 schrieb Herve Boutemy: > >> Or is the idea to have a *fixed* *default* timestamp for all builds? > > > > yes, this is the idea: there is no other option I can imagine to get a > reproducible zip entries timestamp, whatever the precise value of the > timestamp it is > > > > If anybody has any other algorithm idea (that supports wide reality of > situation: not everything is built from Git, for example), I'm all ears open > > > > if people want to discuss the exact default value chosen, we can also: I > don't care about this value, it just has to be defined > > > > Regards, > > > > Hervé > > > > On 2024/09/24 11:49:45 Ceki Gulcu wrote: > >> > >> Hi Hervé, > >> > >> > >> In my opinion, the value of should be > >> part of the pom.xml file and thus visible after the build. Otherwise, > >> how can the build be reproducible? > >> > >> Or is the idea to have a *fixed* *default* timestamp for all builds? > >> > >> -- > >> Ceki Gülcü > >> > >> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > >> > >> > >> > >> On 24/09/2024 11:21, Olivier Lamy wrote: > >>> Hi > >>> It looks like you have some comments on the PR :) > >>> I know it's been implemented as is for a long time now, but I wonder I > >>> (and it looks like a few others) wonder if we could avoid this > >>> "random" build timestamp. > >>> > >>> > >>> On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy > wrote: > > everything is in the title > > Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > PR is https://github.com/apache/maven/pull/1726 > > WDYT about merging this PR as part of the Maven 4 global update? > > 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
> yes, this is the idea: there is no other option I can imagine to get a reproducible zip entries timestamp, whatever the precise value of the timestamp it is > If anybody has any other algorithm idea (that supports wide reality of situation: not everything is built from Git, for example), I'm all ears open For me this looks more like an issue of the jar plugin and should probably be handled there, then even though I wonder why the zip entries need a timestamp for a jar to be reproducible, should it not be enough to compare the zip-entries and leave the timestamp alone? Am 24.09.24 um 22:54 schrieb Herve Boutemy: Or is the idea to have a *fixed* *default* timestamp for all builds? yes, this is the idea: there is no other option I can imagine to get a reproducible zip entries timestamp, whatever the precise value of the timestamp it is If anybody has any other algorithm idea (that supports wide reality of situation: not everything is built from Git, for example), I'm all ears open if people want to discuss the exact default value chosen, we can also: I don't care about this value, it just has to be defined Regards, Hervé On 2024/09/24 11:49:45 Ceki Gulcu wrote: Hi Hervé, In my opinion, the value of should be part of the pom.xml file and thus visible after the build. Otherwise, how can the build be reproducible? Or is the idea to have a *fixed* *default* timestamp for all builds? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 24/09/2024 11:21, Olivier Lamy wrote: Hi It looks like you have some comments on the PR :) I know it's been implemented as is for a long time now, but I wonder I (and it looks like a few others) wonder if we could avoid this "random" build timestamp. On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: everything is in the title Jira issue is https://issues.apache.org/jira/browse/MNG-8258 PR is https://github.com/apache/maven/pull/1726 WDYT about merging this PR as part of the Maven 4 global update? 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Not just that (def value): release plugin will NOT update the timestamp, if value is "inherited" from super POM, as opposed to "property is present in top level reactor POM". At least this is what I see from release sources, may be wrong. Still, the simplest is to have property in the project (parent). Hence I think Maven warning is "cleanest" and also simplest thing we can do for now, especially as Maven4 needs to transparently build Maven3 projects Thanks T On Tue, Sep 24, 2024 at 11:13 PM Manfred Moser wrote: > Fair enough .. that would be good as well. If we have no clear way for a > reasonable default value .. the default can be a warning with advice. > > manfred > > On 2024-09-24 2:06 p.m., Tamás Cservenák wrote: > > Just to tie to the previous message: > > we also discussed making ".mvn" directory _mandatory_ (from mvn4). > > > > So, essentially, if you have a Maven3 project, and you want to build it > > with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" > > directory. This "migration" is IMHO not biggie, as MANY Maven3 projects > > already have ".mvn" directory in the proper place. > > > > (otherwise, currently in Maven3 various code paths, like for start the > one > > in mvn script, then the one in MavenCli kicks in trying to "figure out" > > where is .mvn) > > > > IMHO the same stands for this: warn the user if build is NOT > reproducible, > > starting from Maven4. > > > > Thanks > > T > > > > On Tue, Sep 24, 2024 at 10:59 PM Tamás Cservenák > > wrote: > > > >> Howdy, > >> > >> we discussed this with Guillaume for a bit, and we got to a question: > >> why does Maven not warn IF build is not reproducible? (somehow similar > >> situation as with lack of .mvn directory) > >> > >> Yes, Maven always "does right", but in these two cases (date of the > build > >> and locating .mvn directory) the "heuristics" may be off, way off, and > is > >> better to be explicit. Hence, IMO Maven should just warn "this build is > not > >> reproducible (and you should do this and this to make it reproducible)". > >> > >> No magic, just warn the user. Probably from Maven4 > >> > >> Thanks > >> T > >> > >> > >> > >> On Tue, Sep 24, 2024 at 10:56 PM Herve Boutemy > >> wrote: > >> > Or is the idea to have a *fixed* *default* timestamp for all builds? > >>> yes, this is the idea: there is no other option I can imagine to get a > >>> reproducible zip entries timestamp, whatever the precise value of the > >>> timestamp it is > >>> > >>> If anybody has any other algorithm idea (that supports wide reality of > >>> situation: not everything is built from Git, for example), I'm all > ears open > >>> > >>> if people want to discuss the exact default value chosen, we can also: > I > >>> don't care about this value, it just has to be defined > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> On 2024/09/24 11:49:45 Ceki Gulcu wrote: > Hi Hervé, > > > In my opinion, the value of should be > part of the pom.xml file and thus visible after the build. Otherwise, > how can the build be reproducible? > > Or is the idea to have a *fixed* *default* timestamp for all builds? > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at > https://github.com/sponsors/qos-ch > > > > On 24/09/2024 11:21, Olivier Lamy wrote: > > Hi > > It looks like you have some comments on the PR :) > > I know it's been implemented as is for a long time now, but I wonder > I > > (and it looks like a few others) wonder if we could avoid this > > "random" build timestamp. > > > > > > On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy > >>> wrote: > >> everything is in the title > >> > >> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > >> PR is https://github.com/apache/maven/pull/1726 > >> > >> WDYT about merging this PR as part of the Maven 4 global update? > >> > >> 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 > >>> > >>> > > - > T
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Fair enough .. that would be good as well. If we have no clear way for a reasonable default value .. the default can be a warning with advice. manfred On 2024-09-24 2:06 p.m., Tamás Cservenák wrote: Just to tie to the previous message: we also discussed making ".mvn" directory _mandatory_ (from mvn4). So, essentially, if you have a Maven3 project, and you want to build it with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" directory. This "migration" is IMHO not biggie, as MANY Maven3 projects already have ".mvn" directory in the proper place. (otherwise, currently in Maven3 various code paths, like for start the one in mvn script, then the one in MavenCli kicks in trying to "figure out" where is .mvn) IMHO the same stands for this: warn the user if build is NOT reproducible, starting from Maven4. Thanks T On Tue, Sep 24, 2024 at 10:59 PM Tamás Cservenák wrote: Howdy, we discussed this with Guillaume for a bit, and we got to a question: why does Maven not warn IF build is not reproducible? (somehow similar situation as with lack of .mvn directory) Yes, Maven always "does right", but in these two cases (date of the build and locating .mvn directory) the "heuristics" may be off, way off, and is better to be explicit. Hence, IMO Maven should just warn "this build is not reproducible (and you should do this and this to make it reproducible)". No magic, just warn the user. Probably from Maven4 Thanks T On Tue, Sep 24, 2024 at 10:56 PM Herve Boutemy wrote: Or is the idea to have a *fixed* *default* timestamp for all builds? yes, this is the idea: there is no other option I can imagine to get a reproducible zip entries timestamp, whatever the precise value of the timestamp it is If anybody has any other algorithm idea (that supports wide reality of situation: not everything is built from Git, for example), I'm all ears open if people want to discuss the exact default value chosen, we can also: I don't care about this value, it just has to be defined Regards, Hervé On 2024/09/24 11:49:45 Ceki Gulcu wrote: Hi Hervé, In my opinion, the value of should be part of the pom.xml file and thus visible after the build. Otherwise, how can the build be reproducible? Or is the idea to have a *fixed* *default* timestamp for all builds? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 24/09/2024 11:21, Olivier Lamy wrote: Hi It looks like you have some comments on the PR :) I know it's been implemented as is for a long time now, but I wonder I (and it looks like a few others) wonder if we could avoid this "random" build timestamp. On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: everything is in the title Jira issue is https://issues.apache.org/jira/browse/MNG-8258 PR is https://github.com/apache/maven/pull/1726 WDYT about merging this PR as part of the Maven 4 global update? 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Hi Hervé, Thank you for the clarification. If there is a fixed default timestamp value, then the timestamp in various builds would not respect temporal causality. Also, people looking inside MANIFEST.MF files would get confused. A fixed default timestamp value would inject incorrect information into the build for the sake of reproducibility. The timestamp is not the only obstacle for reproducibility is it? Anyway, and if I may say so, the idea of a fixed timestamp feels wrong. Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 24/09/2024 22:54, Herve Boutemy wrote: Or is the idea to have a *fixed* *default* timestamp for all builds? yes, this is the idea: there is no other option I can imagine to get a reproducible zip entries timestamp, whatever the precise value of the timestamp it is If anybody has any other algorithm idea (that supports wide reality of situation: not everything is built from Git, for example), I'm all ears open if people want to discuss the exact default value chosen, we can also: I don't care about this value, it just has to be defined Regards, Hervé On 2024/09/24 11:49:45 Ceki Gulcu wrote: Hi Hervé, In my opinion, the value of should be part of the pom.xml file and thus visible after the build. Otherwise, how can the build be reproducible? Or is the idea to have a *fixed* *default* timestamp for all builds? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 24/09/2024 11:21, Olivier Lamy wrote: Hi It looks like you have some comments on the PR :) I know it's been implemented as is for a long time now, but I wonder I (and it looks like a few others) wonder if we could avoid this "random" build timestamp. On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: everything is in the title Jira issue is https://issues.apache.org/jira/browse/MNG-8258 PR is https://github.com/apache/maven/pull/1726 WDYT about merging this PR as part of the Maven 4 global update? 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Just to tie to the previous message: we also discussed making ".mvn" directory _mandatory_ (from mvn4). So, essentially, if you have a Maven3 project, and you want to build it with Maven4, you MUST have a ".mvn" directory. You must create a ".mvn" directory. This "migration" is IMHO not biggie, as MANY Maven3 projects already have ".mvn" directory in the proper place. (otherwise, currently in Maven3 various code paths, like for start the one in mvn script, then the one in MavenCli kicks in trying to "figure out" where is .mvn) IMHO the same stands for this: warn the user if build is NOT reproducible, starting from Maven4. Thanks T On Tue, Sep 24, 2024 at 10:59 PM Tamás Cservenák wrote: > Howdy, > > we discussed this with Guillaume for a bit, and we got to a question: > why does Maven not warn IF build is not reproducible? (somehow similar > situation as with lack of .mvn directory) > > Yes, Maven always "does right", but in these two cases (date of the build > and locating .mvn directory) the "heuristics" may be off, way off, and is > better to be explicit. Hence, IMO Maven should just warn "this build is not > reproducible (and you should do this and this to make it reproducible)". > > No magic, just warn the user. Probably from Maven4 > > Thanks > T > > > > On Tue, Sep 24, 2024 at 10:56 PM Herve Boutemy > wrote: > >> > Or is the idea to have a *fixed* *default* timestamp for all builds? >> >> yes, this is the idea: there is no other option I can imagine to get a >> reproducible zip entries timestamp, whatever the precise value of the >> timestamp it is >> >> If anybody has any other algorithm idea (that supports wide reality of >> situation: not everything is built from Git, for example), I'm all ears open >> >> if people want to discuss the exact default value chosen, we can also: I >> don't care about this value, it just has to be defined >> >> Regards, >> >> Hervé >> >> On 2024/09/24 11:49:45 Ceki Gulcu wrote: >> > >> > Hi Hervé, >> > >> > >> > In my opinion, the value of should be >> > part of the pom.xml file and thus visible after the build. Otherwise, >> > how can the build be reproducible? >> > >> > Or is the idea to have a *fixed* *default* timestamp for all builds? >> > >> > -- >> > Ceki Gülcü >> > >> > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch >> > >> > >> > >> > On 24/09/2024 11:21, Olivier Lamy wrote: >> > > Hi >> > > It looks like you have some comments on the PR :) >> > > I know it's been implemented as is for a long time now, but I wonder I >> > > (and it looks like a few others) wonder if we could avoid this >> > > "random" build timestamp. >> > > >> > > >> > > On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy >> wrote: >> > >> >> > >> everything is in the title >> > >> >> > >> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 >> > >> PR is https://github.com/apache/maven/pull/1726 >> > >> >> > >> WDYT about merging this PR as part of the Maven 4 global update? >> > >> >> > >> 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 >> >>
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Howdy, we discussed this with Guillaume for a bit, and we got to a question: why does Maven not warn IF build is not reproducible? (somehow similar situation as with lack of .mvn directory) Yes, Maven always "does right", but in these two cases (date of the build and locating .mvn directory) the "heuristics" may be off, way off, and is better to be explicit. Hence, IMO Maven should just warn "this build is not reproducible (and you should do this and this to make it reproducible)". No magic, just warn the user. Probably from Maven4 Thanks T On Tue, Sep 24, 2024 at 10:56 PM Herve Boutemy wrote: > > Or is the idea to have a *fixed* *default* timestamp for all builds? > > yes, this is the idea: there is no other option I can imagine to get a > reproducible zip entries timestamp, whatever the precise value of the > timestamp it is > > If anybody has any other algorithm idea (that supports wide reality of > situation: not everything is built from Git, for example), I'm all ears open > > if people want to discuss the exact default value chosen, we can also: I > don't care about this value, it just has to be defined > > Regards, > > Hervé > > On 2024/09/24 11:49:45 Ceki Gulcu wrote: > > > > Hi Hervé, > > > > > > In my opinion, the value of should be > > part of the pom.xml file and thus visible after the build. Otherwise, > > how can the build be reproducible? > > > > Or is the idea to have a *fixed* *default* timestamp for all builds? > > > > -- > > Ceki Gülcü > > > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > > > > > > > > On 24/09/2024 11:21, Olivier Lamy wrote: > > > Hi > > > It looks like you have some comments on the PR :) > > > I know it's been implemented as is for a long time now, but I wonder I > > > (and it looks like a few others) wonder if we could avoid this > > > "random" build timestamp. > > > > > > > > > On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy > wrote: > > >> > > >> everything is in the title > > >> > > >> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > > >> PR is https://github.com/apache/maven/pull/1726 > > >> > > >> WDYT about merging this PR as part of the Maven 4 global update? > > >> > > >> 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 > >
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
> Or is the idea to have a *fixed* *default* timestamp for all builds? yes, this is the idea: there is no other option I can imagine to get a reproducible zip entries timestamp, whatever the precise value of the timestamp it is If anybody has any other algorithm idea (that supports wide reality of situation: not everything is built from Git, for example), I'm all ears open if people want to discuss the exact default value chosen, we can also: I don't care about this value, it just has to be defined Regards, Hervé On 2024/09/24 11:49:45 Ceki Gulcu wrote: > > Hi Hervé, > > > In my opinion, the value of should be > part of the pom.xml file and thus visible after the build. Otherwise, > how can the build be reproducible? > > Or is the idea to have a *fixed* *default* timestamp for all builds? > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > > > > On 24/09/2024 11:21, Olivier Lamy wrote: > > Hi > > It looks like you have some comments on the PR :) > > I know it's been implemented as is for a long time now, but I wonder I > > (and it looks like a few others) wonder if we could avoid this > > "random" build timestamp. > > > > > > On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: > >> > >> everything is in the title > >> > >> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > >> PR is https://github.com/apache/maven/pull/1726 > >> > >> WDYT about merging this PR as part of the Maven 4 global update? > >> > >> 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
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Without looking at the details in the PR or issue.. I strongly support this on principle. Maven was always about doing the right thing out of the box. I think this falls very much in that category. +1 Manfred On 2024-09-24 12:03 a.m., Hervé Boutemy wrote: everything is in the title Jira issue is https://issues.apache.org/jira/browse/MNG-8258 PR is https://github.com/apache/maven/pull/1726 WDYT about merging this PR as part of the Maven 4 global update? 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
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Hi Hervé, In my opinion, the value of should be part of the pom.xml file and thus visible after the build. Otherwise, how can the build be reproducible? Or is the idea to have a *fixed* *default* timestamp for all builds? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 24/09/2024 11:21, Olivier Lamy wrote: Hi It looks like you have some comments on the PR :) I know it's been implemented as is for a long time now, but I wonder I (and it looks like a few others) wonder if we could avoid this "random" build timestamp. On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: everything is in the title Jira issue is https://issues.apache.org/jira/browse/MNG-8258 PR is https://github.com/apache/maven/pull/1726 WDYT about merging this PR as part of the Maven 4 global update? 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
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Hi It looks like you have some comments on the PR :) I know it's been implemented as is for a long time now, but I wonder I (and it looks like a few others) wonder if we could avoid this "random" build timestamp. On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy wrote: > > everything is in the title > > Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > PR is https://github.com/apache/maven/pull/1726 > > WDYT about merging this PR as part of the Maven 4 global update? > > 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
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
Reproducible builds are immensely helpful and if this can be supported out of the box I’m all in :) On Tue, Sep 24, 2024 at 09:05 Hervé Boutemy wrote: > everything is in the title > > Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > PR is https://github.com/apache/maven/pull/1726 > > WDYT about merging this PR as part of the Maven 4 global update? > > Regards, > > Hervé > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
