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 environme
> 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 R
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 t
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
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
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,
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
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
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.
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, ess
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
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
> 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 a
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 (pare
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_ (fro
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 inform
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
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
> 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
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 is
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
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
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
>
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 uns
24 matches
Mail list logo
