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
Hi Benjamin,
I'm especially interested in the previous major bumps, not the current one.
For Maven 4 we have 3 hours to go into the details.
We will mention the new Java Runtime version requirement, but I consider that a
change that lifts upon the real majors.
During both Maven2 and Maven3 the J
wow, I did not know that: I really love it
IIUC, these checksum files (per remote repository!) not only cover dependencies
(jars), but also:
- their poms, with parents
- plugins used during build (with their poms and parent...)
I suppose it also cover extensions?
This honestly makes me think at
dependabot[bot] opened a new pull request, #7:
URL: https://github.com/apache/maven-hocon-extension/pull/7
Bumps
[org.junit.jupiter:junit-jupiter](https://github.com/junit-team/junit5) from
5.11.0 to 5.11.1.
Release notes
Sourced from https://github.com/junit-team/junit5/releases"
Howdy,
This page but this table particularly may be of help
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=181305684#MavenEcosystemCleanup-ResolverandMaven
T
On Wed, Sep 25, 2024 at 9:53 PM Robert Scholte wrote:
> Hi Benjamin,
>
> I'm especially interested in the previous maj
Hi Kevin,
The last couple of years these were published to
https://www.youtube.com/@DevoxxForever so would expect the same for this year.
Thanks,
Robert
-Original Message-
From: Kévin Buntrock
Sent: woensdag 25 september 2024 10:22
To: Maven Developers List
Subject: Re: Most signific
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
+1
śr., 25 wrz 2024, 09:07 użytkownik Herve Boutemy
napisał:
> +1
>
> Reproducible Build ok: reference build done with JDK 21 on *nix
>
> Regards,
>
> Hervé
>
> On 2024/09/24 13:08:47 Tamás Cservenák wrote:
> > Howdy,
> >
> > This issue fixes a lingering issue in the whole 3.2.x lineage, that
>
Hello Robert,
The subject piques my curiosity. Do you already know if there'll be a video
available of your presentation?
Kind regards,
Kevin
Le lun. 23 sept. 2024, 21:59, Robert Scholte a
écrit :
> I'm glad I asked the question, because this is indeed a huge and important
> change I was not a
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
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.
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
Hi.
In maven3 we cannot exclude dependencies inherited from parent.
see this
https://stackoverflow.com/questions/2681759/is-there-anyway-to-exclude-artifacts-inherited-from-a-parent-pom
That be kind of annoying if situation comes to be the parent-pom be
maintained by others, and you extend it an
and another idea be we could add a and
(kind of mirror to dependencies and dependencyManagement) to remove those
dependencies from parent &EVERY dependency...
Xeno Amess 于2024年9月25日周三 22:59写道：
> Hi.
>
> In maven3 we cannot exclude dependencies inherited from parent.
>
> see this
>
> https://st
Ran into this also recently (again).
I believe a good way to solve this would be to allow overriding a dependency
inherited from the parent POM with `none` or something like that.
I tried overriding with `provided` but for some reason that
didn't seem to work.
The context was trying that I typi
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
+1
On Tue, 24 Sept 2024 at 15:10, Tamás Cservenák wrote:
> Howdy,
>
> This issue fixes a lingering issue in the whole 3.2.x lineage, that
> resulted in "bad passphrase" on Windows OS with GPG signer.
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=123
+1
Reproducible Build ok: reference build done with JDK 21 on *nix
Regards,
Hervé
On 2024/09/24 13:08:47 Tamás Cservenák wrote:
> Howdy,
>
> This issue fixes a lingering issue in the whole 3.2.x lineage, that
> resulted in "bad passphrase" on Windows OS with GPG signer.
>
> We solved 3 issues
+1
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
+1
Michael Osipov 于2024年9月25日周三 22:08写道：
>
> +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
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,
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
dependabot[bot] opened a new pull request, #7:
URL: https://github.com/apache/maven-xinclude-extension/pull/7
Bumps
[org.junit.jupiter:junit-jupiter](https://github.com/junit-team/junit5) from
5.11.0 to 5.11.1.
Release notes
Sourced from https://github.com/junit-team/junit5/releas
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
I think skipping 9 Java versions between Maven 3 and 4 is a big deal and
has never happened before 😁
Java 17 will be required for Maven 4.
Also Maven 4: extensions where you can use pom.conf or pom.yml etc.
On Mon, 23 Sept 2024, 10:53 Robert Scholte, wrote:
> Hi all,
>
>
>
> Within 2 weeks I w
> 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
26 matches
Mail list logo
