Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Slawomir Jaranowski]

pt., 5 sty 2024 o 16:17 Michael Osipov  napisał(a):

> On 2024/01/05 14:03:11 Slawomir Jaranowski wrote:
> > Hi,
> >
> > My summary for this discussion:
> >
> > No objection for change: Tamás Cservenák, Anders Hammar, Olivier Lamy,
> > Sylwester Lachiewicz, Jorge Solórzano, Gary Gregory, Hervé Boutemy
> >
> > Michael Osipov - had a questions but I assume that is no -1 from him
>
> Clearly not -1, I just want to see a plan before I give a reasonable vote.
>
>
Can you remember me what plan or procedure we have followed during
switching plugins requirements to 3.2.5.


> > So:
> >
> > I would like to not categorize cora and not core plugins - simply we
> have a
> > list of plugins which is maintain by Maven team:
> > https://maven.apache.org/plugins/index.html
>
> We have that already in the above mention page..
>
> > I will send a dedicated email to the dev and users list about plans.
>
> Can you prepare a draft first, please?
>
>
Yes I can prepare one.. but old email in such cases like make version EOL
or switching requirements for plugins will be helpful.



> > I will update documentations and sites about new requirements:
> >  - https://maven.apache.org/developers/compatibility-plan.html
> >  - https://maven.apache.org/docs/history.html
> >  -
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup
> >
> > With nexts release of plugins we should add "Requirements History"
> >
> > We have a list of current Plugins requirements:
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
> Lookting at these, I'd like to see the retirement of all 2.2.1 compatible
> plugins. No one found the time/motivation/need to left them to 3.x. We
> should clear the premises before we raise the bar otherwise that does not
> look good at all.
>
> Thanks for working on this...
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Slawomir Jaranowski]

I would like to kindly remember that this thread is not about the JDK
version, if we need such discussion we should start a new thread.

pt., 5 sty 2024 o 18:22 Karl Heinz Marbaise 
napisał(a):

> On 05.01.24 17:02, Michael Osipov wrote:
> > On 2024/01/05 15:52:54 Karl Heinz Marbaise wrote:
> >> ...
> >> On 05.01.24 16:19, Michael Osipov wrote:
> >>> On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:
>  +1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
>  minimum runtime requirement..
> >>>
> >>> This reminds me of https://github.com/openssl/openssl/issues/10902
> and it provides very good reasons why not to do it. Maven is a low level
> tool -- as such it has to be available to as many devs as possible.
> >>
> >> Hm.. I have to admit that I don't see the relationship to OpenSSL and
> >> C++ compilers / Perl etc. and which reason do you have in mind?
> >
> > It is about replacing Perl with CMake. Perl has a much better
> availability than CMake...
>
> And where is the relationship to Maven? Apart from that Perl is not that
> available on a lot of systems (the last 10 years have changed that)...
> today Python is often more available than Perl... which would bring
> CMake back into the game...
>
> Furthermore not many people are building Curl from sources... I would
> say 99% of people consume them via their package manager (dnf, yum, apt
> etc.) of their distributions or via flatpak or alike...Who is building
> from source today?
>
> So I don't see here the in relationship to Maven... or are we talking
> about bootstrapping Maven from source without pre existing Maven/Ant etc. ?
>
> >
> >> But for Maven 4. I see no problem in upgrading the minimum requirement
> >> to JDK 17 (runtime)... If people can not upgrade (for whatever reason)
> >> they can continue to use Maven 3.X ... Also as I mentioned several times
> >> before even with JDK 17 you can build code for java 7... and if that is
> >> not sufficient you can use Toolchain... (also mentioned several times
> >> before)...
> >>
> >> Apart from that if I take that argument in consequence (also mentioned
> >> several times before)... than we have to stop any upgrade in JDK minimum
> >> version and go back to JDK 1.5 or even 1.4 (or even less)...because
> >> there are people using those ancient versions...
> >
> > Please don't apply our possiblites to others and don't make any
> assumptions what others can or cannot do. Rasing to 17 w/o massively
> rewriting core to benefit from post-8 constructs a pure lie to ourselves.
> We cannot even keep JIRA issue count low. I'd really focus on what really
> matters.
>
> I have given solutions to solve possible issues... and now I should not
> show possible solutions... very interesting...
>
>
> Why is massively rewriting required? In Maven core (master branch)  is
> already using a lot of JDK 8 parts.. which can be increased of course,
> for example using JDK17 as base line would make it possible to use
> sealed classes, records, var usage etc. only to mention a few... of
> course that will take time no doubt about that...(mentioned several
> times before)...
>
> Also staying on old things (JDK8 is old) will not attract new developers
> which is a thing in particular in relationship to the mentioned part
> about JIRA issues etc. meaning the number of contributors could be
> higher...
>
> Which is from my point of view exactly the opposite argument.. upgrade
> to most recent JDK 17 at min ... or even JDK 21... to get better
> attraction for other possible contributors..
>
>
> >
> >> https://www.jetbrains.com/lp/devecosystem-2023/java/
> >> https://www.jetbrains.com/lp/devecosystem-2022/java/
> >> https://www.jetbrains.com/lp/devecosystem-2021/java/
> >
> > This represents nothing especially not those who aren't or cannot
> advertise what thy use. Never trust statistics you haven't falsified
> yourself.
>
> You should check the
> https://www.jetbrains.com/lp/devecosystem-2022/methodology/ etc. That's
> available for all given reports. You can get the raw data...
>
>
>  > not those who aren't or cannot advertise what thy use.
>
> If they can not use more recent things they can continue to use Maven
> 3... (mentioned before).. that contradicts in itself.. described
> solutions which work and that should not be shown/mentioned...makes no
> sense.
>
> Those statistics mention things like usage of JDK 7, 6 and even 5. What
> is the problem here? Only those reports show that the number of the
> usage for JDK5,6,7 is very low...not to say extremely low...
>
> Based on which argument do you conclude that we can not to upgrade to
> JDK 17  or even to JDK 21: for Maven 4?
>
> 1. It needs time to change things in core
> 2. We would exclude people (discussion about how many?) who can not
> upgrade.
>
>
> Answers to them:
> 1. It has taken time to incorporate changes for JDK 8 in core and
> plugins etc.. and it will take time to change more of course..  no doubt
> about that.
> 2. Mentioned solutions for 

Re: Nexus returns 400 Bad Request

[Romain Manni-Bucau]

Hi,

This is a valid error but if you want to see it you need to enable HTTP
frames.

For the record the error returns a HTML response with this content: *Cannot
find a matching staging profile*.

If you want to check them out it depends a bit of your maven version but
for 3.9 you just comment the two last lines
of $MAVEN_HOME/conf/logging/simplelogger.properties
(org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for
maven 4 you can use the JVM httpclient system properties IIRC).

But agree our client could be more precise on the error instead of just
throwing a 400 without any message, if you feel motivated to send a pr it
would be welcomed I guess.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 5 janv. 2024 à 18:46, Michael Osipov  a écrit :

>
> On 2024/01/04 14:00:08 tison wrote:
> > Hi,
> >
> > When deploying artifacts to Nexus repository, 400 Bad Request can be
> > one of the most confusing error code. See [1] as an example.
> >
> > Sonatype has a page to document some common causes of 400 Bad Request
> > [2]. But I wonder if we can return an error message (diagnostic) along
> > with the error code, so that users can get what conditions broken
> > exactly.
> >
> > I suppose it has been discussed before. Is there any reference about
> > this? What is the related components / code I can check for potential
> > contributions (fixes)?
> >
> > Best,
> > tison.
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-25344
> > [2] https://central.sonatype.org/faq/400-error/
>
> Looking at the INFRA issue it seems that 400 is just wrong. There is not
> client issue here, but a permission issue which should give you 403. Maybe
> that is a bug in Nexus itself.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Nexus returns 400 Bad Request

[Michael Osipov]

On 2024/01/04 14:00:08 tison wrote:
> Hi,
> 
> When deploying artifacts to Nexus repository, 400 Bad Request can be
> one of the most confusing error code. See [1] as an example.
> 
> Sonatype has a page to document some common causes of 400 Bad Request
> [2]. But I wonder if we can return an error message (diagnostic) along
> with the error code, so that users can get what conditions broken
> exactly.
> 
> I suppose it has been discussed before. Is there any reference about
> this? What is the related components / code I can check for potential
> contributions (fixes)?
> 
> Best,
> tison.
> 
> [1] https://issues.apache.org/jira/browse/INFRA-25344
> [2] https://central.sonatype.org/faq/400-error/

Looking at the INFRA issue it seems that 400 is just wrong. There is not client 
issue here, but a permission issue which should give you 403. Maybe that is a 
bug in Nexus itself.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Karl Heinz Marbaise]

On 05.01.24 17:02, Michael Osipov wrote:

On 2024/01/05 15:52:54 Karl Heinz Marbaise wrote:

...
On 05.01.24 16:19, Michael Osipov wrote:

On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:

+1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
minimum runtime requirement..


This reminds me of https://github.com/openssl/openssl/issues/10902 and it 
provides very good reasons why not to do it. Maven is a low level tool -- as 
such it has to be available to as many devs as possible.


Hm.. I have to admit that I don't see the relationship to OpenSSL and
C++ compilers / Perl etc. and which reason do you have in mind?


It is about replacing Perl with CMake. Perl has a much better availability than 
CMake...


And where is the relationship to Maven? Apart from that Perl is not that
available on a lot of systems (the last 10 years have changed that)...
today Python is often more available than Perl... which would bring
CMake back into the game...

Furthermore not many people are building Curl from sources... I would
say 99% of people consume them via their package manager (dnf, yum, apt
etc.) of their distributions or via flatpak or alike...Who is building
from source today?

So I don't see here the in relationship to Maven... or are we talking
about bootstrapping Maven from source without pre existing Maven/Ant etc. ?




But for Maven 4. I see no problem in upgrading the minimum requirement
to JDK 17 (runtime)... If people can not upgrade (for whatever reason)
they can continue to use Maven 3.X ... Also as I mentioned several times
before even with JDK 17 you can build code for java 7... and if that is
not sufficient you can use Toolchain... (also mentioned several times
before)...

Apart from that if I take that argument in consequence (also mentioned
several times before)... than we have to stop any upgrade in JDK minimum
version and go back to JDK 1.5 or even 1.4 (or even less)...because
there are people using those ancient versions...


Please don't apply our possiblites to others and don't make any assumptions 
what others can or cannot do. Rasing to 17 w/o massively rewriting core to 
benefit from post-8 constructs a pure lie to ourselves. We cannot even keep 
JIRA issue count low. I'd really focus on what really matters.


I have given solutions to solve possible issues... and now I should not
show possible solutions... very interesting...


Why is massively rewriting required? In Maven core (master branch)  is
already using a lot of JDK 8 parts.. which can be increased of course,
for example using JDK17 as base line would make it possible to use
sealed classes, records, var usage etc. only to mention a few... of
course that will take time no doubt about that...(mentioned several
times before)...

Also staying on old things (JDK8 is old) will not attract new developers
which is a thing in particular in relationship to the mentioned part
about JIRA issues etc. meaning the number of contributors could be higher...

Which is from my point of view exactly the opposite argument.. upgrade
to most recent JDK 17 at min ... or even JDK 21... to get better
attraction for other possible contributors..





https://www.jetbrains.com/lp/devecosystem-2023/java/
https://www.jetbrains.com/lp/devecosystem-2022/java/
https://www.jetbrains.com/lp/devecosystem-2021/java/


This represents nothing especially not those who aren't or cannot advertise 
what thy use. Never trust statistics you haven't falsified yourself.


You should check the
https://www.jetbrains.com/lp/devecosystem-2022/methodology/ etc. That's
available for all given reports. You can get the raw data...


> not those who aren't or cannot advertise what thy use.

If they can not use more recent things they can continue to use Maven
3... (mentioned before).. that contradicts in itself.. described
solutions which work and that should not be shown/mentioned...makes no
sense.

Those statistics mention things like usage of JDK 7, 6 and even 5. What
is the problem here? Only those reports show that the number of the
usage for JDK5,6,7 is very low...not to say extremely low...

Based on which argument do you conclude that we can not to upgrade to
JDK 17  or even to JDK 21: for Maven 4?

1. It needs time to change things in core
2. We would exclude people (discussion about how many?) who can not upgrade.


Answers to them:
1. It has taken time to incorporate changes for JDK 8 in core and
plugins etc.. and it will take time to change more of course..  no doubt
about that.
2. Mentioned solutions for that. (continue to use Maven 3.X; Toolchain).

Are those things a reason not to lift ? No.

Furthermore So that means your own arguments are now contradicted...

Many other tools and libraries and frameworks already did that (Spring
Boot 3(JDK 17), Quarkus(JDK 17), Micronaut (JDK 17) etc., . and even
Jakarta EE 11 has set even JDK 21 as baseline...
(https://jakarta.ee/specifications/platform/11/)


Kind regards
Karl Heinz Marbaise




M

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Michael Osipov]

On 2024/01/05 15:52:54 Karl Heinz Marbaise wrote:
> ...
> On 05.01.24 16:19, Michael Osipov wrote:
> > On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:
> >> +1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
> >> minimum runtime requirement..
> >
> > This reminds me of https://github.com/openssl/openssl/issues/10902 and it 
> > provides very good reasons why not to do it. Maven is a low level tool -- 
> > as such it has to be available to as many devs as possible.
> 
> Hm.. I have to admit that I don't see the relationship to OpenSSL and
> C++ compilers / Perl etc. and which reason do you have in mind?

It is about replacing Perl with CMake. Perl has a much better availability than 
CMake...

> But for Maven 4. I see no problem in upgrading the minimum requirement
> to JDK 17 (runtime)... If people can not upgrade (for whatever reason)
> they can continue to use Maven 3.X ... Also as I mentioned several times
> before even with JDK 17 you can build code for java 7... and if that is
> not sufficient you can use Toolchain... (also mentioned several times
> before)...
> 
> Apart from that if I take that argument in consequence (also mentioned
> several times before)... than we have to stop any upgrade in JDK minimum
> version and go back to JDK 1.5 or even 1.4 (or even less)...because
> there are people using those ancient versions...

Please don't apply our possiblites to others and don't make any assumptions 
what others can or cannot do. Rasing to 17 w/o massively rewriting core to 
benefit from post-8 constructs a pure lie to ourselves. We cannot even keep 
JIRA issue count low. I'd really focus on what really matters.

> https://www.jetbrains.com/lp/devecosystem-2023/java/
> https://www.jetbrains.com/lp/devecosystem-2022/java/
> https://www.jetbrains.com/lp/devecosystem-2021/java/

This represents nothing especially not those who aren't or cannot advertise 
what thy use. Never trust statistics you haven't falsified yourself.

M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Karl Heinz Marbaise]

...
On 05.01.24 16:19, Michael Osipov wrote:

On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:

+1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
minimum runtime requirement..


This reminds me of https://github.com/openssl/openssl/issues/10902 and it 
provides very good reasons why not to do it. Maven is a low level tool -- as 
such it has to be available to as many devs as possible.


Hm.. I have to admit that I don't see the relationship to OpenSSL and
C++ compilers / Perl etc. and which reason do you have in mind?


But for Maven 4. I see no problem in upgrading the minimum requirement
to JDK 17 (runtime)... If people can not upgrade (for whatever reason)
they can continue to use Maven 3.X ... Also as I mentioned several times
before even with JDK 17 you can build code for java 7... and if that is
not sufficient you can use Toolchain... (also mentioned several times
before)...

Apart from that if I take that argument in consequence (also mentioned
several times before)... than we have to stop any upgrade in JDK minimum
version and go back to JDK 1.5 or even 1.4 (or even less)...because
there are people using those ancient versions...


https://www.jetbrains.com/lp/devecosystem-2023/java/
https://www.jetbrains.com/lp/devecosystem-2022/java/
https://www.jetbrains.com/lp/devecosystem-2021/java/

Kind regards
Karl Heinz Marbaise



M

-
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: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Michael Osipov]

On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote:
> +1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
> minimum runtime requirement..

This reminds me of https://github.com/openssl/openssl/issues/10902 and it 
provides very good reasons why not to do it. Maven is a low level tool -- as 
such it has to be available to as many devs as possible.

M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Michael Osipov]

On 2024/01/05 14:03:11 Slawomir Jaranowski wrote:
> Hi,
> 
> My summary for this discussion:
> 
> No objection for change: Tamás Cservenák, Anders Hammar, Olivier Lamy,
> Sylwester Lachiewicz, Jorge Solórzano, Gary Gregory, Hervé Boutemy
> 
> Michael Osipov - had a questions but I assume that is no -1 from him

Clearly not -1, I just want to see a plan before I give a reasonable vote.

> So:
> 
> I would like to not categorize cora and not core plugins - simply we have a
> list of plugins which is maintain by Maven team:
> https://maven.apache.org/plugins/index.html

We have that already in the above mention page..

> I will send a dedicated email to the dev and users list about plans.

Can you prepare a draft first, please?

> I will update documentations and sites about new requirements:
>  - https://maven.apache.org/developers/compatibility-plan.html
>  - https://maven.apache.org/docs/history.html
>  - https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup
> 
> With nexts release of plugins we should add "Requirements History"
> 
> We have a list of current Plugins requirements:
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

Lookting at these, I'd like to see the retirement of all 2.2.1 compatible 
plugins. No one found the time/motivation/need to left them to 3.x. We should 
clear the premises before we raise the bar otherwise that does not look good at 
all.

Thanks for working on this...

M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Karl Heinz Marbaise]

Hi,

I'm the same opinion to upgrade to the most recent Maven 3.X version..
for the plugins... +1 (but I'm ok also to use Maven 3.6.3 as minimum)..


+1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as
minimum runtime requirement..


Kind regards
Karl Heinz Marbaise

On 31.12.23 00:54, Tamás Cservenák wrote:

+1 to Jorge.

As I understand it, this is the "minimal version supported" (prerequisite)
we talk about here. But imo 3.x plugins should compile against lastest 3.x
Maven.

T

On Sun, Dec 31, 2023, 00:35 Jorge Solórzano  wrote:


I know that a build tool is different from a framework, but we are again
missing the point here, is not about framework vs build tools, the point is
that newer projects already require new Java versions, and if legacy
projects require using an old Java version, then those projects will still
be using Maven 3.x anyway and that is perfectly fine. What should be the
threshold to move to a newer Java version? (I'm talking about using Java 11
on Maven 4.0, not on 3.x).

Sorry I didn't want to hijack this thread for the Java version discussion,
yet I wish to know what is the benefit of "supporting" plugins on older
versions of Maven, I'm asking as a user since I'm not a Maven core
developer, PMC,r committer, just an occasional contributor, and again, I
might be missing something, but what is the benefit of updating plugins on
a project and using an older version of Maven? As a user is weird to me
that Maven versions prior 3.8.x are EOL, yet plugins provide Maven API
compatibility down to 3.2.5.

It seems that is indeed a new challenge to require Maven 3.6.3 as minimal
for core plugins ;)

Regards and Happy New Year!


On Sat, Dec 30, 2023 at 6:30 PM Michael Osipov 
wrote:


Am 2023-12-30 um 16:43 schrieb Jorge Solórzano:

I'm a bit confused here, why would anyone update Maven plugins in a

project

and NOT update Maven Core? Older versions of Maven are EOL, is expected
that Maven Core is backward-compatible on minor releases so updating

Maven

Core should be straightforward. I might be missing something but I

don't

see a scenario where someone updates plugins but does not update Maven
itself, I would expect the opposite, it should be more common to update
Maven core than plugins (although that is just my perception).

The question remains: Why should we use 3.5.4 instead of 3.6.3 as a

minimum

in plugins? don't get me wrong, I don't mind if we use 3.5.4 instead of
3.6.3 if the maintenance/support is the same, but knowing that CI uses
Maven 3.6.3 and newer, and without knowing why plugins should be

supported

on 3.5.4, my vote will go to use 3.6.3.

This discussion reminds me of the minimum required Java version, there

was

even an informal poll
 with more

than

80% asking for newer Java releases, and I would love to see Maven 4.0
require at least Java 11, but here we are, one year later and still on

Java

8 because some prefer to be working with Java 7 or even Java 6. The
ecosystem is moving forward, SpringBoot, Quarkus, Jakarta EE, and some
dependencies are slowly moving to at least Java 11, if a project

requires

Java 8 (for whatever reason), then it will remain on Maven 3.x, moving

to

Java 11 is conservative enough for Maven 4.0.


Those who are working with JDK less than 8 are already a minority...

https://www.jetbrains.com/lp/devecosystem-2023/java/

Also the usage of JDK 17 is increasing... I expect that JDK21 will
increase over this year...



You are confusing a low-level tool which should be accessible to
everyone compared to a specific framework. Regarding Spring Boot: I
consider that a total dick move dropping javax namespace support for a
huge user base. Regardless of the Java version.

M









-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Slawomir Jaranowski]

Hi,

My summary for this discussion:

No objection for change: Tamás Cservenák, Anders Hammar, Olivier Lamy,
Sylwester Lachiewicz, Jorge Solórzano, Gary Gregory, Hervé Boutemy

Michael Osipov - had a questions but I assume that is no -1 from him

So:

I would like to not categorize cora and not core plugins - simply we have a
list of plugins which is maintain by Maven team:
https://maven.apache.org/plugins/index.html

I will send a dedicated email to the dev and users list about plans.

I will update documentations and sites about new requirements:
 - https://maven.apache.org/developers/compatibility-plan.html
 - https://maven.apache.org/docs/history.html
 - https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup

With nexts release of plugins we should add "Requirements History"

We have a list of current Plugins requirements:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html


pt., 5 sty 2024 o 08:57 Hervé Boutemy  napisał(a):

> for the records, "Maven Plugins Compatibility Plan" strategy is stored in
>  https://maven.apache.org/developers/compatibility-plan.html
>
> = the doc to refer to and update if necessary after the current discussion
>
> Le vendredi 29 décembre 2023, 14:42:17 CET Slawomir Jaranowski a écrit :
> > Hi,
> >
> > Last year we mark all Maven versions 3.6.x and older as EOL [1]
> >
> > But we still try to support minimal API version for Core Maven Plugins as
> > 3.2.5
> >
> > I would like to  propose to sich it for at least to 3.6.3
> >
> > Reasonable reasons: (for me)
> >  - for standard CI build we use Maven 3.6.3 and newer
> >  - many of external plugins, like MojoHaus are switched to 3.6.3
> >  - we have a hacks in code to try support old version in plugin, like
> > in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can cleanup
> > such code
> > - I don't believe to someone want to do more fixes for EOL Maven version
> in
> > plugins - so we should be a honest for users
> > - and we should go forward
> >
> > [1] https://maven.apache.org/docs/history.html
> > [2]
> >
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report
> >
> -plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPlu
> > ginDescriptorBuilder.java
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski