+1 from me (not that my opinion should count for much here)
From: Manfred Moser
Date: Monday, 6 January 2025 at 16:51
To: [email protected]
Subject: Re: Using git forks
This email was sent to you by someone outside the University.
You should only click on links or attachments if you are
All,
I’ve written some code to extend the enforcer plugin to include a “mutually
exclusive profiles” rule. I’m ready to submit a Pull Request, but I’m not quite
sure of the correct procedure.
In my own projects, I tend to work primarily off a develop branch, folding
features into that and
ttps://medium.com/google-cloud/squash-java-linkage-bugs-before-they-bite-92af79e31bfd>>
It is fine to publish this from your own repo without involving the
Maven Project.
On Tue, Jan 7, 2025 at 10:02 PM Andy Law wrote:
>
> All,
>
> I’ve written some code to extend the enforcer pl
I’m a lurker on this list, albeit one that’s wanting to find time to add a
feature to the enforcer plugin.
I’m with Tamás on this, not least because then all code updates will be coming
in through the same route, be they from you outstanding worthies or from us
occasional self-interest
content is safe.
Please start by filing an issue describing what the intended rule will
do. It's easier to understand in prose than code.
On Tue, Jan 7, 2025 at 10:02 PM Andy Law wrote:
>
> All,
>
> I’ve written some code to extend the enforcer plugin to include a “mutually
>
…and then I realised that this relates to the “Migration from JIRA” thread…
From: Andy Law
Date: Wednesday, 8 January 2025 at 09:35
To: Maven Developers List
Subject: Re: Contributing a Pull Request for the enforcer plugin - branch
etiquette
That would be easier if there was an ‘Issues’ tab on
As more of a wider question, why would this not be specified in the Parent POM
if it were adopted as an “approved” dependency?
Later,
Andy
From: Matthias Bünger
Date: Monday, 21 July 2025 at 18:40
To: [email protected]
Subject: Re: The use of AssertJ assertions
Hi all,
while I really
Subject: Re: Proposal: new default directory layout for modular project
Le 2025-05-15 à 20 h 26, Andy Law a écrit :
>
> I confess that I was using “standard” in the context of what I
> understand to be the _Maven_ standard, since this is the Maven
> developers list
>
The core issue is
problem that didn’t really exist. Can someone please point
me towards the discussion behind the introduction of that element so I can
understand it better?
Later,
Andy
From: Andy Law
Date: Thursday, 15 May 2025 at 20:44
To: Maven Developers List
Subject: Re: Proposal: new default directory layout
Although I’m just a lurker here, the idea of promoting the use of rebase on a
shared repository seems incredibly dangerous. Or “brave” as some would put it.
Later,
Andy
From: Tibor Digana
Date: Tuesday, 5 August 2025 at 15:01
To: Maven Developers List
Subject: Re: [VOTE] Introduce Prevent
From: Romain Manni-Bucau
Date: Friday, 16 May 2025 at 08:10
To: Maven Developers List
Subject: Re: Proposal: new default directory layout for modular project
The most natural way is to do parent/moduleX/src/main/java (and siblings)
and handle the compiler plugin in parent to be jpms specific, no
7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T%2Fri55jBDhEwCgmfgG7I0clc%2BwmP59nIJMlhY3g%2BVQk%3D&reserved=0()<https://maven.apache.org/ref/4.0.0-rc-3/apidocs/org/apache/maven/api/model/Source.html#getModule>
Le ven. 16 mai 2025 à 14:28, Andy Law a écrit :
> From: Romain Manni
@maven.apache.org
Subject: Re: Proposal: new default directory layout for modular project
Le 2025-05-16 à 14 h 27, Andy Law a écrit :
>> The most natural way is to do parent/moduleX/src/main/java (and
siblings)
>> and handle the compiler plugin in parent to be jpms specific, no
technical
&g
I don’t understand why this is so different from an aggregated project, with
${module} above src, but I may be missing the point because I’ve not spent any
time thinking about JPMS yet.
You’re going to give me headaches navigating if you put ${module} anywhere
below either ${scope} or ${lang}
=Fgw3%2Fr5hOKttd5O0tMJIqpuRBLVoEe3k9LOnjtFxnms%3D&reserved=0<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>>
Le jeu. 15 mai 2025 à 19:23, Martin Desruisseaux <
[email protected]> a écrit :
> Le 2025-05-15 à 19 h 03, Andy Law a éc
: Proposal: new default directory layout for modular project
Le 2025-05-15 à 19 h 54, Andy Law a écrit :
>
> Or maybe go the whole hog and define a new type
> specifically for jpms and just use the standard layouts underneath that?
>
Does "standard layouts" means "layout de
target use
case?
Later,
Andy
From: Martin Desruisseaux
Date: Friday, 16 May 2025 at 16:27
To: [email protected]
Subject: Re: Proposal: new default directory layout for modular project
Le 2025-05-16 à 15 h 01, Andy Law a écrit :
>
> OK. I see the purpose of the tag now.
>
To e
From: Martin Desruisseaux
Date: Saturday, 17 May 2025 at 17:46
To: Andy Law , Maven Developers List
Subject: Re: Proposal: new default directory layout for modular project
Le 2025-05-17 à 18 h 30, Andy Law a écrit :
How do multi-release and multi-module relate one to another
From the user&#
Are all those bits of “compatibility code” annotated as @Deprecated?
Later,
Andy
From: Guillaume Nodet
Date: Tuesday, 3 June 2025 at 09:20
To: Maven Developers List
Subject: Re: current setup is leaking quality: [S1161] "@override" should be
used on overriding members
FWIW, most if not all
Only if they consider it “gross” to be reminded that they are using free
software that someone, somewhere created and is giving away. If their attitude
is “I don’t want to be told that” then they'll be able to read the fine
documentation and work out how to set the environment variable that
...And the third type - those who never thought about it.
...And the ones who did, but didn’t know where to start to ask
(But apart from that, what have the Romans ever done for us…)
And if you don’t want to see it, then set the environment variable or property
to turn it off and carry on. This
my releases of PLC4X as an example … depending on which PLC4X
> release you would refer to, you’d get 6 different places to go to … so this
> might frustrate people (If they keep on using ancient versions)
>
> Chris
>
>
> Von: Andy Law
> Datum: Donnerstag, 28. August 2025 um
I’m not sure that “every end user” feels that this is an issue, and I’m still
struggling to understand why splitting a monolithic artifact into several
separate modules would ever be considered a minor update.
But, hey. I have popcorn…
Later,
Andy
From: Vladimir Sitnikov
Date: Wednesday, 5
To clarify, I mean how is what Bruno is proposing different from versions:set
in concept i.e., a “command line” way to easily edit the pom file(s) for a
project?
Later,
Andy
From: Andy Law
Date: Tuesday, 31 March 2026 at 21:18
To: Maven Developers List
Subject: Re: [PROPOSAL] Add
To throw a slightly different, semi-supportive angle into this, how is what
Bruno is proposing different from versions:set?
Later,
Andy
From: Bruno Borges
Date: Tuesday, 31 March 2026 at 20:56
To: Maven Developers List
Subject: Re: [PROPOSAL] Add dependency:add, dependency:remove, and
I just read an article on foojay - in info/advert for a tool that checks
dependency updates for suspicious signs
(https://foojay.io/today/this-dependency-update-looked-exactly-like-an-account-takeover/).
Initially, I thought, “that needs to be converted into a plugin”, and then I
realised that
Isn't one of the main features of logging that you can do all this by defining
your own logging infrastructure and reporting level “on the fly"?
Later,
Andy
From: Claude Warren
Date: Saturday, 3 October 2026 at 14:49
To: Maven Developers List
Cc: [email protected]
Subject: Re: More log
27 matches
Mail list logo
