Re: [DISCUSS] New Maven Core API for 4.x

[Hervé BOUTEMY]

Le lundi 14 mars 2022, 16:43:51 CET Michael Osipov a écrit :
> MASSIVE! Nothing else to say.
+1

> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
do you think that we would do first Maven 4.0.0-alpha releases as 1 global 
release, to have a first stabilisation, before splitting the API+models in a 
second set of betas?

note to self: do an updated dependency graph based on
  https://maven.apache.org/ref/4-LATEST/
to clearly see the split between the API+models vs core

probably we'll need to write a plan on our Wiki

> * upgrade plugins to the new API, deprecate old components and API
this one will take time, given the work at Maven side and at community level
This will IMHO span the whole Maven 4 life time

> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
this is one may be for Maven 5...



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

Re: Dependencies from profiles broken in 3.8.5?

[Tamás Cservenák]

Can you expose some reproducer of the issue you have, or maybe the project
that fails with maven 3.8.5?

T

On Mon, Mar 14, 2022 at 8:06 PM Falko Modler  wrote:

> Thanks for checking! In fact, I would have been very surprised if that was
> broken in general.
>
> Right now I'm suspecting user property parsing but I have yet to take a
> closer look...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Dependencies from profiles broken in 3.8.5?

[Falko Modler]

Thanks for checking! In fact, I would have been very surprised if that was 
broken in general.

Right now I'm suspecting user property parsing but I have yet to take a closer 
look...

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

Re: Dependencies from profiles broken in 3.8.5?

[Tamás Cservenák]

Howdy,

I tried but could not reproduce this with 3.8.5: when I do `-PmyProfile`
with dependencies declared in profile, the dependencies ARE there (tried
with full GAV but also managed dependencies, where profile had only GA but
version came from depMgt).

IMHO, this is somewhere else

HTH
T



On Mon, Mar 14, 2022 at 6:48 PM Falko Modler  wrote:

> Hi everyone,
>
> before I invest (a lot of) time, is it just me or are dependencies from
> profiles broken in Maven 3.8.5?
>
> In my Quarkus project, two usecases broke with 3.8.5 but they are fine
> with 3.8.4 and before.
>
> One is described briefly here:
> https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067049568
>
> Has anything changed in that area in 3.8.5?
>
> At this point it could also be an incompatibility issue with Quarkus,
> which is why I'd appreciate some pointers in the right direction.
>
> Thanks!
>
> Cheers,
>
> Falko
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Test scope and transitive dependencies in compile scope

[Slawomir Jaranowski]

Hi,

We have open issue MDEP-791 [1] for maven dependency plugin
There are also connected issues for Maven core MNG-6058 [2] and
probably others.

Do we have any idea how this should be resolved ... fix in m-dependency-p
or in Maven core?

I'm afraid that even if we fix in core ... we should have some workaround
in m-dependency-p depending on using the Maven core version ... or this way
is wrong ...

[1] https://issues.apache.org/jira/browse/MDEP-791
[2] https://issues.apache.org/jira/browse/MNG-6058

-- 
Sławomir Jaranowski

Dependencies from profiles broken in 3.8.5?

[Falko Modler]

Hi everyone,

before I invest (a lot of) time, is it just me or are dependencies from
profiles broken in Maven 3.8.5?

In my Quarkus project, two usecases broke with 3.8.5 but they are fine
with 3.8.4 and before.

One is described briefly here:
https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067049568

Has anything changed in that area in 3.8.5?

At this point it could also be an incompatibility issue with Quarkus,
which is why I'd appreciate some pointers in the right direction.

Thanks!

Cheers,

Falko


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

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Slawomir Jaranowski]

Hi

First sentence: Set this to "true" to ignore a failure during testing.

It is clear for me - we want to ignore a failure during testing ... So if
the testing process is not starting for any reason or was broken for
reasons other than test failure this property should not be considered.

Most of the case we use it in CI systems for generating test reports to
analyze trends of test stability and so on ...

So if the report of tests is not generated or is truncated property should
not be considered.

And last, surefire has plenty of parameters, introduced next one for cover
1% of cases is form over substance.

Surefire code and configuration is complicated enough. We should find a way
to simplify it - not introduce something more complicated.

Current code of surefire is difficult to understand, we have many corner
cases introduced by plenty of configuration options.
When we have simpler code, bug fix will be easier, more contributors can
help us to improve.
Now we see every bug, new features produce a lot of noise and it is a
problem to merge it.

And in consequence when users wait two years for fixing something ... I
don't think they are happy about it.


pon., 14 mar 2022 o 02:55 Tibor Digana  napisał(a):

> In case of the user property *maven.test.failure.ignore* the MOJO must not
> throw any exception which is interpreted by the Maven Core as BUILD
> SUCCESS.
>
> We have received an internal requirement to change the behavior of the user
> property *maven.test.failure.ignore* so that the behavior will have one
> exception.
>
> Suppose that you have JDK 1.8 but you use:
> /jre/java --add-reads ...
> The outcome is JVM exit with an error message.
> I agree with Herve who also says that  *maven.test.failure.ignore* should
> not allow the MOJO to throw the exception. It is not a typical JVM
> segmentation fault or another JVM crash where we cannot do anything about
> it, and where the entire build would crash in the command line which
> of course means that the build cannot normally be interpreted as BUILD
> SUCCESS. So we are still on the same level of failures related to the test
> purposes.
>
> On the other hand, Olivier has reopened the issues SUREFIRE-1426 and
> SUREFIRE-1681 where the exceptional behavior of the feature is expected.
> This is exactly the reason why I closed these tickets several years ago and
> my proposal was to not to have any exceptions in the feature behavior and
> the proposal was to introduce a new user property for exact use cases.
> The next idea, which comes from two developers, would provide us with the
> same non exceptional and exact behavior of the user property
> *maven.test.failure.ignore* but it would also provide us with new user
> property in the case with fine grade control of the build errors, e.g.
> *maven.test.jvm.error.ignore*.
>
>
> I would like to open the discussion on this topic. You're welcome!
>
>
> Cheers
> Tibor
>


-- 
Sławomir Jaranowski

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Slawomir Jaranowski]

pon., 14 mar 2022 o 10:52 Tibor Digana  napisał(a):

> Romain, it is not a bug.
> Don't consider this as a bug. It was a feature request for change by
> Olivier, and not a bug.
> I closed both issues years ago but not because of ignorance but because the
> appearance of the exceptional behavior is a wrong compromise and which does
> not help anyone and even it makes the situation worse because typically
> other group of users would fire a new Jira tickets. You would not be able
> to satisfy two contradictory parties which have completely different
> opinions, and so we use to introduce new params and this way we satisfy
> both parties, they may combine the params as they wish, and everybody would
> be happy and nobody would claim. Many technical solutions might exist, e.g.
> param=boolean|string or new param=boolean, whatever.
>
> The truth is that this problem with (java --add-reads ...) happened in our
> ASF environment on Java 8 which in good configuration would not happen and
> should not.
> It is not right way that we abuse "maven.test.failure.ignore" which would
> tell us "Hey, you have illegal configuration in your build system and it
> would not work by JDK design", it is not the goal of the plugin to tell you
> that you have configured the build wrong because it won't and the same
> configuration of the plugin (not the build)  says "ignore the error".
>

 So what is the difference:

mvn test -Dmaven.test.failure.ignore=true
-Dsurefire.rerunFailingTestsCount=notanumber

mvn test -Dmaven.test.failure.ignore=true -DargLine=-Xxx

for both I have illegal configuration in my build system, but one brak
Maven build and one does not ...


Yesterday I discussed this problem with Herve and we independently observed
> equal opinions and that's not everything because we understood that the
> purpose of the config parameter is to not throw MOJO exception which is
> right, but the exceptional behavior should have an exact new param for the
> exact use case.
> SPI for this parameter is too much because no user would implement it for a
> trivial parameter;; the SPI is used to be implemented by frameworks or
> systems or application servers but this is not our case.
>
>
>
>
> On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau 
> wrote:
>
> > +1
> > if it is to investigate a CI issue, it is generally easy to add debug
> > insights (by code or agent) so a SPI sounds like the sanest for the
> plugin
> > to me.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 14 mars 2022 à 09:08, Guillaume Nodet  a
> écrit
> > :
> >
> > > If that's not currently possible, maybe a SPI should be provided so
> that
> > > people can use plug in extensions to analyze the test result and
> override
> > > it if necessary (transforming an error into a warning, storing results
> > in a
> > > way which is easier to use by other tools later...) ?
> > >
> > > Guillaume
> > >
> > > Le lun. 14 mars 2022 à 07:43, Christoph Läubrich 
> a
> > > écrit :
> > >
> > > > I also agree that the test at least should run, we use this property
> to
> > > > run the test and produce result and later on have a buildstep that
> > > > analyze the results (and probably fail the build job).
> > > >
> > > > As it is not recommend, I wonder what is the recommended way to
> archive
> > > > something similar?
> > > >
> > > > Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > > > > On Mon, 14 Mar 2022 at 11:55, Tibor Digana  >
> > > > wrote:
> > > > >
> > > > >> In case of the user property *maven.test.failure.ignore* the MOJO
> > must
> > > > not
> > > > >> throw any exception which is interpreted by the Maven Core as
> BUILD
> > > > >> SUCCESS.
> > > > >>
> > > > >
> > > > > This is a very simple reduction of the problem description.
> > > > > The documentation here
> > > > >
> > > >
> > >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore
> > > > > says
> > > > > "Set this to "true" to ignore a failure during testing. Its use is
> > NOT
> > > > > RECOMMENDED, but quite convenient on occasion"
> > > > >
> > > > > Personally, I understand this to ignore failures in junit results
> BUT
> > > at
> > > > > least I want the tests to run.
> > > > > I guess this is how our users use this feature (feature we do not
> > > > recommend
> > > > > by the way...)
> > > > > And this is perfectly explained here
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077
> > > > > there is a difference between ignoring some junit failures and
> > > ignoring a
> > > > >

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Bernd Eckenfels]

Hello,

I really think no sane developer should use stable distributions like EL or 
Debian für Java/Maven toolchains. But if they do, they do know they have old 
software and their vendor will do the maintenance. I would not be concerned 
with that (besides maybe clearly communicating EOLs, minimum versions and 
requirements). Of course you could try to negotiate with the biggest 
distributions on a common ground, but that will mean more versions than today 
(not less) - so why waste your cycles…

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Jorge Solórzano 
Gesendet: Monday, March 14, 2022 4:31:35 PM
An: Maven Developers List 
Betreff: Re: [DISCUSS] Radical Fast Forward to 3.5.4

FYI, it looks like RHEL-based 7 uses maven 3.0.5, RHEL-based 8 uses
3.5.4 and 3.6.3.

My guess is that even if the new upgraded plugins depend on Maven
3.5.4 it wouldn't cause major issues as if anyone is using an olver
Maven version they will likely use older versions of the
plugins/components.

Anyway, as Hervé mentioned, there is a lack of better documentation of
the compatibility of plugins, and based on this page
https://maven.apache.org/developers/compatibility-plan.html since Jun
2020, plugins can have Java 8 prerequisite, and even for Maven 3.8.x
that means a breaking change.


On Mon, Mar 14, 2022 at 3:40 PM Elliotte Rusty Harold
 wrote:
>
> FYI Debian Stable is at 3.6.3 as is Ubuntu. Homebrew is at 3.8. I've
> only checked the websites for this, not tried to install from there.
> However neither looks like a blocker.
>
> What other package managers should we check? What does Red Hat use? Windows?
>
> Also, are there any older versions of OS's likely to be in use that
> have older package managers?
>
>
>
> On Sun, Mar 13, 2022 at 7:57 PM Elliotte Rusty Harold
>  wrote:
> >
> > What do all the various package managers install? I'm pretty sure I've
> > seen one lately whose default was 3.3.1. Debian perhaps?
> >
> > I think before we make any such move it would make sense to audit what
> > people who don't manually install Maven are likely to have. First we
> > should raise all those to 3.5.4 or later. Then we can upgrade the
> > minimum version.
> >
> > Even more ambitiously, perhaps we should rethink how maven is
> > installed. Why should it come from anywhere but Maven Central, and why
> > can't a pom.xml specify the version of Maven itself? All we really
> > should install is a very simple bootstrap script. But that's probably
> > a discussion for another day. Let's get the package managers
> > straightened out first.
> >
> > On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:
> > >
> > > Folks,
> > >
> > > as you might now we are dragging old luggage over and over with every
> > > new year. We are making (little) progress with cleansing, skimming and
> > > updating of our components.
> > >
> > > I'll will make a radical proposal I have already discussed privately
> > > with other fellow committers over Slack:
> > > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > > intermediaries. Reasoning:
> > > * Maven 3.5.4 is almost 4 old, it is settled
> > > * Everything before we shouls consider ancient, if you haven't moved
> > > yet, you will not and it will be your problem.
> > > * It is the first version which uses Maven Resolver [1]
> > > * It will free resources to test with previous releases which most don't
> > > do anyway
> > > * Maybe this will make it even easier to migrate to the upcoming Maven
> > > Core API
> > >
> > > WDYT?
> > >
> > > Michael
> > >
> > > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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: [DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

I suppose you could raise PRs to the origin/mvn4 branch ? Maybe even commit
changes directly, if that makes sense.

Le lun. 14 mars 2022 à 16:43, Michael Osipov  a écrit :

> Am 2022-03-14 um 08:59 schrieb Guillaume Nodet:
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> to
> > 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> >* fix some problems with designs that do not work well with
> multithreading
> >* offer a way to finally get rid of deprecated code
> >* offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> >* offer an homogeneous and a bit more modern API
> >* completely hide the maven-resolver, so that it can finally upgrade
> to a
> > v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1].  Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api.  The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3].  The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build.  This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> >* continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> >* release the API, then maven-core supporting the new API
> >* upgrade plugins to the new API, deprecate old components and API
> >* once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
>
> MASSIVE! Nothing else to say. I have taken a look at [1] and see already
> room for improvement. What is the best way to comment on code?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Slawomir Jaranowski]

Hi,

As I and others wrote - we should have clear documentation about release
and version policy.

Maintainers / contributors of package managers should take care about
updating their products. It can not be our responsibility and moreover a
blocker for us.

We have basic instructions on how to install Maven, it doesn't even require
administrator privilege - Maven can be installed in user space.


pon., 14 mar 2022 o 16:32 Jorge Solórzano  napisał(a):

> FYI, it looks like RHEL-based 7 uses maven 3.0.5, RHEL-based 8 uses
> 3.5.4 and 3.6.3.
>
> My guess is that even if the new upgraded plugins depend on Maven
> 3.5.4 it wouldn't cause major issues as if anyone is using an olver
> Maven version they will likely use older versions of the
> plugins/components.
>
> Anyway, as Hervé mentioned, there is a lack of better documentation of
> the compatibility of plugins, and based on this page
> https://maven.apache.org/developers/compatibility-plan.html since Jun
> 2020, plugins can have Java 8 prerequisite, and even for Maven 3.8.x
> that means a breaking change.
>
>
> On Mon, Mar 14, 2022 at 3:40 PM Elliotte Rusty Harold
>  wrote:
> >
> > FYI Debian Stable is at 3.6.3 as is Ubuntu. Homebrew is at 3.8. I've
> > only checked the websites for this, not tried to install from there.
> > However neither looks like a blocker.
> >
> > What other package managers should we check? What does Red Hat use?
> Windows?
> >
> > Also, are there any older versions of OS's likely to be in use that
> > have older package managers?
> >
> >
> >
> > On Sun, Mar 13, 2022 at 7:57 PM Elliotte Rusty Harold
> >  wrote:
> > >
> > > What do all the various package managers install? I'm pretty sure I've
> > > seen one lately whose default was 3.3.1. Debian perhaps?
> > >
> > > I think before we make any such move it would make sense to audit what
> > > people who don't manually install Maven are likely to have. First we
> > > should raise all those to 3.5.4 or later. Then we can upgrade the
> > > minimum version.
> > >
> > > Even more ambitiously, perhaps we should rethink how maven is
> > > installed. Why should it come from anywhere but Maven Central, and why
> > > can't a pom.xml specify the version of Maven itself? All we really
> > > should install is a very simple bootstrap script. But that's probably
> > > a discussion for another day. Let's get the package managers
> > > straightened out first.
> > >
> > > On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov 
> wrote:
> > > >
> > > > Folks,
> > > >
> > > > as you might now we are dragging old luggage over and over with every
> > > > new year. We are making (little) progress with cleansing, skimming
> and
> > > > updating of our components.
> > > >
> > > > I'll will make a radical proposal I have already discussed privately
> > > > with other fellow committers over Slack:
> > > > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > > > intermediaries. Reasoning:
> > > > * Maven 3.5.4 is almost 4 old, it is settled
> > > > * Everything before we shouls consider ancient, if you haven't moved
> > > > yet, you will not and it will be your problem.
> > > > * It is the first version which uses Maven Resolver [1]
> > > > * It will free resources to test with previous releases which most
> don't
> > > > do anyway
> > > > * Maybe this will make it even easier to migrate to the upcoming
> Maven
> > > > Core API
> > > >
> > > > WDYT?
> > > >
> > > > Michael
> > > >
> > > > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> > > >
> > > > [1]
> > > >
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.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
>
>

-- 
Sławomir Jaranowski

Re: [DISCUSS] New Maven Core API for 4.x

[Michael Osipov]

Am 2022-03-14 um 08:59 schrieb Guillaume Nodet:

Hi everyone,

As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
3.5.4" thread, I'd like to start the discussion around it.

Over the past weeks, I've worked on an experimental API for Maven 4.x.
The goals are multiple :
   * fix some problems with designs that do not work well with multithreading
   * offer a way to finally get rid of deprecated code
   * offer a complete API (which would deprecate m-artifact-transfer,
m-dependency-tree)
   * offer an homogeneous and a bit more modern API
   * completely hide the maven-resolver, so that it can finally upgrade to a
v2 with the package renamed without too much disturbance

The goal would be to extract the models and API in a separate project with
a much lower release cycle, as those rarely change, but are currently
released with each version of maven.

The current API can be seen at [1].  Note that the plugins API has also
been included within the new API and the plugin tools have been updated so
that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
new flag has been added to the MojoDescriptor to know if the plugin is
using the old or the new api.  The plugin testing harness tools have been
updated to junit 5 and now provide a few annotations [2] to help writing
plugin tests [3].  The maven-core has been enhanced to support loading
those new v4 plugins along with the v3 ones, which means they can work
side-by-side in the same build.  This is done by implementing the new API
by wrapping the v3 implementation classes (such as MavenSession,
MavenProject, etc...) [4].
I've ported a few plugins such as clean [5], install [6], deploy [7] as a
proof-of-concept that this actually works.

The very rough goal would be to to have multiple phases:
   * continue the work on this API so that it can actually cover all use
cases for plugins, create a new project with the new API and models, make
sure plugins can work correctly with the new API / implementation
   * release the API, then maven-core supporting the new API
   * upgrade plugins to the new API, deprecate old components and API
   * once all plugins have migrated to the new API, switch maven-core
implementation to the new API

I'm eager to hear your thoughts !

[1]
https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
[2]
https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
[3]
https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
[4]
https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
[5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
[6] https://github.com/apache/maven-install-plugin/tree/mvn4/
[7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/



MASSIVE! Nothing else to say. I have taken a look at [1] and see already 
room for improvement. What is the best way to comment on code?


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

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Jorge Solórzano]

FYI, it looks like RHEL-based 7 uses maven 3.0.5, RHEL-based 8 uses
3.5.4 and 3.6.3.

My guess is that even if the new upgraded plugins depend on Maven
3.5.4 it wouldn't cause major issues as if anyone is using an olver
Maven version they will likely use older versions of the
plugins/components.

Anyway, as Hervé mentioned, there is a lack of better documentation of
the compatibility of plugins, and based on this page
https://maven.apache.org/developers/compatibility-plan.html since Jun
2020, plugins can have Java 8 prerequisite, and even for Maven 3.8.x
that means a breaking change.


On Mon, Mar 14, 2022 at 3:40 PM Elliotte Rusty Harold
 wrote:
>
> FYI Debian Stable is at 3.6.3 as is Ubuntu. Homebrew is at 3.8. I've
> only checked the websites for this, not tried to install from there.
> However neither looks like a blocker.
>
> What other package managers should we check? What does Red Hat use? Windows?
>
> Also, are there any older versions of OS's likely to be in use that
> have older package managers?
>
>
>
> On Sun, Mar 13, 2022 at 7:57 PM Elliotte Rusty Harold
>  wrote:
> >
> > What do all the various package managers install? I'm pretty sure I've
> > seen one lately whose default was 3.3.1. Debian perhaps?
> >
> > I think before we make any such move it would make sense to audit what
> > people who don't manually install Maven are likely to have. First we
> > should raise all those to 3.5.4 or later. Then we can upgrade the
> > minimum version.
> >
> > Even more ambitiously, perhaps we should rethink how maven is
> > installed. Why should it come from anywhere but Maven Central, and why
> > can't a pom.xml specify the version of Maven itself? All we really
> > should install is a very simple bootstrap script. But that's probably
> > a discussion for another day. Let's get the package managers
> > straightened out first.
> >
> > On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:
> > >
> > > Folks,
> > >
> > > as you might now we are dragging old luggage over and over with every
> > > new year. We are making (little) progress with cleansing, skimming and
> > > updating of our components.
> > >
> > > I'll will make a radical proposal I have already discussed privately
> > > with other fellow committers over Slack:
> > > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > > intermediaries. Reasoning:
> > > * Maven 3.5.4 is almost 4 old, it is settled
> > > * Everything before we shouls consider ancient, if you haven't moved
> > > yet, you will not and it will be your problem.
> > > * It is the first version which uses Maven Resolver [1]
> > > * It will free resources to test with previous releases which most don't
> > > do anyway
> > > * Maybe this will make it even easier to migrate to the upcoming Maven
> > > Core API
> > >
> > > WDYT?
> > >
> > > Michael
> > >
> > > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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: [DISCUSS] Radical Fast Forward to 3.5.4

[Elliotte Rusty Harold]

FYI Debian Stable is at 3.6.3 as is Ubuntu. Homebrew is at 3.8. I've
only checked the websites for this, not tried to install from there.
However neither looks like a blocker.

What other package managers should we check? What does Red Hat use? Windows?

Also, are there any older versions of OS's likely to be in use that
have older package managers?



On Sun, Mar 13, 2022 at 7:57 PM Elliotte Rusty Harold
 wrote:
>
> What do all the various package managers install? I'm pretty sure I've
> seen one lately whose default was 3.3.1. Debian perhaps?
>
> I think before we make any such move it would make sense to audit what
> people who don't manually install Maven are likely to have. First we
> should raise all those to 3.5.4 or later. Then we can upgrade the
> minimum version.
>
> Even more ambitiously, perhaps we should rethink how maven is
> installed. Why should it come from anywhere but Maven Central, and why
> can't a pom.xml specify the version of Maven itself? All we really
> should install is a very simple bootstrap script. But that's probably
> a discussion for another day. Let's get the package managers
> straightened out first.
>
> On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:
> >
> > Folks,
> >
> > as you might now we are dragging old luggage over and over with every
> > new year. We are making (little) progress with cleansing, skimming and
> > updating of our components.
> >
> > I'll will make a radical proposal I have already discussed privately
> > with other fellow committers over Slack:
> > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > intermediaries. Reasoning:
> > * Maven 3.5.4 is almost 4 old, it is settled
> > * Everything before we shouls consider ancient, if you haven't moved
> > yet, you will not and it will be your problem.
> > * It is the first version which uses Maven Resolver [1]
> > * It will free resources to test with previous releases which most don't
> > do anyway
> > * Maybe this will make it even easier to migrate to the upcoming Maven
> > Core API
> >
> > WDYT?
> >
> > Michael
> >
> > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Romain Manni-Bucau]

@Tibor: I never said it was a bug, my point is that you never needs it so
we should keep that deprecated/not recommended and enable people having too
constrained env to work on it through a SPI as proposed by Guillaume. So
proposal was to drop that property support and add a SPI if anyone think
this property is needed.

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



Le lun. 14 mars 2022 à 10:57, Christoph Läubrich  a
écrit :

> Just wondering but maybe it would be better to configure the severity
> instead of a true/false, something like:
>
> maven.test.failure=WARN
> maven.test.error=ERROR
>
> would only warn about failing tests but thrw exception if starting the
> test fails?
>
> Am 14.03.22 um 10:52 schrieb Tibor Digana:
> > Romain, it is not a bug.
> > Don't consider this as a bug. It was a feature request for change by
> > Olivier, and not a bug.
> > I closed both issues years ago but not because of ignorance but because
> the
> > appearance of the exceptional behavior is a wrong compromise and which
> does
> > not help anyone and even it makes the situation worse because typically
> > other group of users would fire a new Jira tickets. You would not be able
> > to satisfy two contradictory parties which have completely different
> > opinions, and so we use to introduce new params and this way we satisfy
> > both parties, they may combine the params as they wish, and everybody
> would
> > be happy and nobody would claim. Many technical solutions might exist,
> e.g.
> > param=boolean|string or new param=boolean, whatever.
> >
> > The truth is that this problem with (java --add-reads ...) happened in
> our
> > ASF environment on Java 8 which in good configuration would not happen
> and
> > should not.
> > It is not right way that we abuse "maven.test.failure.ignore" which would
> > tell us "Hey, you have illegal configuration in your build system and it
> > would not work by JDK design", it is not the goal of the plugin to tell
> you
> > that you have configured the build wrong because it won't and the same
> > configuration of the plugin (not the build)  says "ignore the error".
> > Yesterday I discussed this problem with Herve and we independently
> observed
> > equal opinions and that's not everything because we understood that the
> > purpose of the config parameter is to not throw MOJO exception which is
> > right, but the exceptional behavior should have an exact new param for
> the
> > exact use case.
> > SPI for this parameter is too much because no user would implement it
> for a
> > trivial parameter;; the SPI is used to be implemented by frameworks or
> > systems or application servers but this is not our case.
> >
> >
> >
> >
> > On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> +1
> >> if it is to investigate a CI issue, it is generally easy to add debug
> >> insights (by code or agent) so a SPI sounds like the sanest for the
> plugin
> >> to me.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>
> >>
> >> Le lun. 14 mars 2022 à 09:08, Guillaume Nodet  a
> écrit
> >> :
> >>
> >>> If that's not currently possible, maybe a SPI should be provided so
> that
> >>> people can use plug in extensions to analyze the test result and
> override
> >>> it if necessary (transforming an error into a warning, storing results
> >> in a
> >>> way which is easier to use by other tools later...) ?
> >>>
> >>> Guillaume
> >>>
> >>> Le lun. 14 mars 2022 à 07:43, Christoph Läubrich 
> a
> >>> écrit :
> >>>
>  I also agree that the test at least should run, we use this property
> to
>  run the test and produce result and later on have a buildstep that
>  analyze the results (and probably fail the build job).
> 
>  As it is not recommend, I wonder what is the recommended way to
> archive
>  something similar?
> 
>  Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
>  wrote:
> >
> >> In case of the user property *maven.test.failure.ignore* the MOJO
> >> must
>  not
> >> throw any exception which is interpreted by the Maven Core as BUILD
> >> SUCCESS.
> >>
> >
> > This is a very simple reduction of the problem description.
> > The documentation here
> >
> 
> >>>
> >>
> https://maven.apache.org/surefire/maven-surefire-plugin/

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Christoph Läubrich]

Just wondering but maybe it would be better to configure the severity 
instead of a true/false, something like:


maven.test.failure=WARN
maven.test.error=ERROR

would only warn about failing tests but thrw exception if starting the 
test fails?


Am 14.03.22 um 10:52 schrieb Tibor Digana:

Romain, it is not a bug.
Don't consider this as a bug. It was a feature request for change by
Olivier, and not a bug.
I closed both issues years ago but not because of ignorance but because the
appearance of the exceptional behavior is a wrong compromise and which does
not help anyone and even it makes the situation worse because typically
other group of users would fire a new Jira tickets. You would not be able
to satisfy two contradictory parties which have completely different
opinions, and so we use to introduce new params and this way we satisfy
both parties, they may combine the params as they wish, and everybody would
be happy and nobody would claim. Many technical solutions might exist, e.g.
param=boolean|string or new param=boolean, whatever.

The truth is that this problem with (java --add-reads ...) happened in our
ASF environment on Java 8 which in good configuration would not happen and
should not.
It is not right way that we abuse "maven.test.failure.ignore" which would
tell us "Hey, you have illegal configuration in your build system and it
would not work by JDK design", it is not the goal of the plugin to tell you
that you have configured the build wrong because it won't and the same
configuration of the plugin (not the build)  says "ignore the error".
Yesterday I discussed this problem with Herve and we independently observed
equal opinions and that's not everything because we understood that the
purpose of the config parameter is to not throw MOJO exception which is
right, but the exceptional behavior should have an exact new param for the
exact use case.
SPI for this parameter is too much because no user would implement it for a
trivial parameter;; the SPI is used to be implemented by frameworks or
systems or application servers but this is not our case.




On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau 
wrote:


+1
if it is to investigate a CI issue, it is generally easy to add debug
insights (by code or agent) so a SPI sounds like the sanest for the plugin
to me.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance





Le lun. 14 mars 2022 à 09:08, Guillaume Nodet  a écrit
:


If that's not currently possible, maybe a SPI should be provided so that
people can use plug in extensions to analyze the test result and override
it if necessary (transforming an error into a warning, storing results

in a

way which is easier to use by other tools later...) ?

Guillaume

Le lun. 14 mars 2022 à 07:43, Christoph Läubrich  a
écrit :


I also agree that the test at least should run, we use this property to
run the test and produce result and later on have a buildstep that
analyze the results (and probably fail the build job).

As it is not recommend, I wonder what is the recommended way to archive
something similar?

Am 14.03.22 um 06:29 schrieb Olivier Lamy:

On Mon, 14 Mar 2022 at 11:55, Tibor Digana 

wrote:



In case of the user property *maven.test.failure.ignore* the MOJO

must

not

throw any exception which is interpreted by the Maven Core as BUILD
SUCCESS.



This is a very simple reduction of the problem description.
The documentation here






https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore

says
"Set this to "true" to ignore a failure during testing. Its use is

NOT

RECOMMENDED, but quite convenient on occasion"

Personally, I understand this to ignore failures in junit results BUT

at

least I want the tests to run.
I guess this is how our users use this feature (feature we do not

recommend

by the way...)
And this is perfectly explained here






https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077

there is a difference between ignoring some junit failures and

ignoring a

configuration error because some jvm args has been misconfigured for

many

reasons and surefire cannot start.

If I follow your reasoning ("MOJO must not throw any exception ") we

should

ignore every surefire configuration error and keep running the build

until

the end and says BUILD SUCCESS
what about

mvn test -Dsurefire.rerunFailingTestsCount=notanumber
-Dmaven.test.failure.ignore=true

we should not throw any exceptions as you said below and keep saying

BUILD

SUCCESS?
argLine is a configuration element as any others so it should fail

directly

and not be ignored especially w

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

Romain, it is not a bug.
Don't consider this as a bug. It was a feature request for change by
Olivier, and not a bug.
I closed both issues years ago but not because of ignorance but because the
appearance of the exceptional behavior is a wrong compromise and which does
not help anyone and even it makes the situation worse because typically
other group of users would fire a new Jira tickets. You would not be able
to satisfy two contradictory parties which have completely different
opinions, and so we use to introduce new params and this way we satisfy
both parties, they may combine the params as they wish, and everybody would
be happy and nobody would claim. Many technical solutions might exist, e.g.
param=boolean|string or new param=boolean, whatever.

The truth is that this problem with (java --add-reads ...) happened in our
ASF environment on Java 8 which in good configuration would not happen and
should not.
It is not right way that we abuse "maven.test.failure.ignore" which would
tell us "Hey, you have illegal configuration in your build system and it
would not work by JDK design", it is not the goal of the plugin to tell you
that you have configured the build wrong because it won't and the same
configuration of the plugin (not the build)  says "ignore the error".
Yesterday I discussed this problem with Herve and we independently observed
equal opinions and that's not everything because we understood that the
purpose of the config parameter is to not throw MOJO exception which is
right, but the exceptional behavior should have an exact new param for the
exact use case.
SPI for this parameter is too much because no user would implement it for a
trivial parameter;; the SPI is used to be implemented by frameworks or
systems or application servers but this is not our case.




On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau 
wrote:

> +1
> if it is to investigate a CI issue, it is generally easy to add debug
> insights (by code or agent) so a SPI sounds like the sanest for the plugin
> to me.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 14 mars 2022 à 09:08, Guillaume Nodet  a écrit
> :
>
> > If that's not currently possible, maybe a SPI should be provided so that
> > people can use plug in extensions to analyze the test result and override
> > it if necessary (transforming an error into a warning, storing results
> in a
> > way which is easier to use by other tools later...) ?
> >
> > Guillaume
> >
> > Le lun. 14 mars 2022 à 07:43, Christoph Läubrich  a
> > écrit :
> >
> > > I also agree that the test at least should run, we use this property to
> > > run the test and produce result and later on have a buildstep that
> > > analyze the results (and probably fail the build job).
> > >
> > > As it is not recommend, I wonder what is the recommended way to archive
> > > something similar?
> > >
> > > Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > > > On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
> > > wrote:
> > > >
> > > >> In case of the user property *maven.test.failure.ignore* the MOJO
> must
> > > not
> > > >> throw any exception which is interpreted by the Maven Core as BUILD
> > > >> SUCCESS.
> > > >>
> > > >
> > > > This is a very simple reduction of the problem description.
> > > > The documentation here
> > > >
> > >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore
> > > > says
> > > > "Set this to "true" to ignore a failure during testing. Its use is
> NOT
> > > > RECOMMENDED, but quite convenient on occasion"
> > > >
> > > > Personally, I understand this to ignore failures in junit results BUT
> > at
> > > > least I want the tests to run.
> > > > I guess this is how our users use this feature (feature we do not
> > > recommend
> > > > by the way...)
> > > > And this is perfectly explained here
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077
> > > > there is a difference between ignoring some junit failures and
> > ignoring a
> > > > configuration error because some jvm args has been misconfigured for
> > many
> > > > reasons and surefire cannot start.
> > > >
> > > > If I follow your reasoning ("MOJO must not throw any exception ") we
> > > should
> > > > ignore every surefire configuration error and keep running the build
> > > until
> > > > the end and says BUILD SUCCESS
> > > > what about
> > > >
> > > > mvn test -Dsurefire.rerunFailingTestsCount=notanumber
> > > > -Dmaven.test.failure.ignore=true
> > > >
> > > > we should not throw any exceptions as you said below and keep saying
> > > BUIL

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Romain Manni-Bucau]

+1
if it is to investigate a CI issue, it is generally easy to add debug
insights (by code or agent) so a SPI sounds like the sanest for the plugin
to me.

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



Le lun. 14 mars 2022 à 09:08, Guillaume Nodet  a écrit :

> If that's not currently possible, maybe a SPI should be provided so that
> people can use plug in extensions to analyze the test result and override
> it if necessary (transforming an error into a warning, storing results in a
> way which is easier to use by other tools later...) ?
>
> Guillaume
>
> Le lun. 14 mars 2022 à 07:43, Christoph Läubrich  a
> écrit :
>
> > I also agree that the test at least should run, we use this property to
> > run the test and produce result and later on have a buildstep that
> > analyze the results (and probably fail the build job).
> >
> > As it is not recommend, I wonder what is the recommended way to archive
> > something similar?
> >
> > Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > > On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
> > wrote:
> > >
> > >> In case of the user property *maven.test.failure.ignore* the MOJO must
> > not
> > >> throw any exception which is interpreted by the Maven Core as BUILD
> > >> SUCCESS.
> > >>
> > >
> > > This is a very simple reduction of the problem description.
> > > The documentation here
> > >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore
> > > says
> > > "Set this to "true" to ignore a failure during testing. Its use is NOT
> > > RECOMMENDED, but quite convenient on occasion"
> > >
> > > Personally, I understand this to ignore failures in junit results BUT
> at
> > > least I want the tests to run.
> > > I guess this is how our users use this feature (feature we do not
> > recommend
> > > by the way...)
> > > And this is perfectly explained here
> > >
> >
> https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077
> > > there is a difference between ignoring some junit failures and
> ignoring a
> > > configuration error because some jvm args has been misconfigured for
> many
> > > reasons and surefire cannot start.
> > >
> > > If I follow your reasoning ("MOJO must not throw any exception ") we
> > should
> > > ignore every surefire configuration error and keep running the build
> > until
> > > the end and says BUILD SUCCESS
> > > what about
> > >
> > > mvn test -Dsurefire.rerunFailingTestsCount=notanumber
> > > -Dmaven.test.failure.ignore=true
> > >
> > > we should not throw any exceptions as you said below and keep saying
> > BUILD
> > > SUCCESS?
> > > argLine is a configuration element as any others so it should fail
> > directly
> > > and not be ignored especially when the surefire plugin cannot run.
> > >
> > >
> > >> We have received an internal requirement to change the behavior of the
> > user
> > >> property *maven.test.failure.ignore* so that the behavior will have
> one
> > >> exception.
> > >
> > > Suppose that you have JDK 1.8 but you use:
> > >> /jre/java --add-reads ...
> > >> The outcome is JVM exit with an error message.
> > >> I agree with Herve who also says that  *maven.test.failure.ignore*
> > should
> > >> not allow the MOJO to throw the exception. It is not a typical JVM
> > >> segmentation fault or another JVM crash where we cannot do anything
> > about
> > >> it, and where the entire build would crash in the command line which
> > >> of course means that the build cannot normally be interpreted as BUILD
> > >> SUCCESS. So we are still on the same level of failures related to the
> > test
> > >> purposes.
> > >>
> > >> On the other hand, Olivier has reopened the issues SUREFIRE-1426 and
> > >> SUREFIRE-1681 where the exceptional behavior of the feature is
> expected.
> > >> This is exactly the reason why I closed these tickets several years
> ago
> > and
> > >> my proposal was to not to have any exceptions in the feature behavior
> > and
> > >> the proposal was to introduce a new user property for exact use cases.
> > >> The next idea, which comes from two developers, would provide us with
> > the
> > >> same non exceptional and exact behavior of the user property
> > >> *maven.test.failure.ignore* but it would also provide us with new user
> > >> property in the case with fine grade control of the build errors, e.g.
> > >> *maven.test.jvm.error.ignore*.
> > >>
> > >
> > > with a default of?
> > > honestly I just see this new parameter as introducing more complexity
> in
> > an
> > > already very complex code and not worth it.
> > > again read both issue's comments and my comments.
> > > Please try to have a use

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Guillaume Nodet]

If that's not currently possible, maybe a SPI should be provided so that
people can use plug in extensions to analyze the test result and override
it if necessary (transforming an error into a warning, storing results in a
way which is easier to use by other tools later...) ?

Guillaume

Le lun. 14 mars 2022 à 07:43, Christoph Läubrich  a
écrit :

> I also agree that the test at least should run, we use this property to
> run the test and produce result and later on have a buildstep that
> analyze the results (and probably fail the build job).
>
> As it is not recommend, I wonder what is the recommended way to archive
> something similar?
>
> Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
> wrote:
> >
> >> In case of the user property *maven.test.failure.ignore* the MOJO must
> not
> >> throw any exception which is interpreted by the Maven Core as BUILD
> >> SUCCESS.
> >>
> >
> > This is a very simple reduction of the problem description.
> > The documentation here
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore
> > says
> > "Set this to "true" to ignore a failure during testing. Its use is NOT
> > RECOMMENDED, but quite convenient on occasion"
> >
> > Personally, I understand this to ignore failures in junit results BUT at
> > least I want the tests to run.
> > I guess this is how our users use this feature (feature we do not
> recommend
> > by the way...)
> > And this is perfectly explained here
> >
> https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077
> > there is a difference between ignoring some junit failures and ignoring a
> > configuration error because some jvm args has been misconfigured for many
> > reasons and surefire cannot start.
> >
> > If I follow your reasoning ("MOJO must not throw any exception ") we
> should
> > ignore every surefire configuration error and keep running the build
> until
> > the end and says BUILD SUCCESS
> > what about
> >
> > mvn test -Dsurefire.rerunFailingTestsCount=notanumber
> > -Dmaven.test.failure.ignore=true
> >
> > we should not throw any exceptions as you said below and keep saying
> BUILD
> > SUCCESS?
> > argLine is a configuration element as any others so it should fail
> directly
> > and not be ignored especially when the surefire plugin cannot run.
> >
> >
> >> We have received an internal requirement to change the behavior of the
> user
> >> property *maven.test.failure.ignore* so that the behavior will have one
> >> exception.
> >
> > Suppose that you have JDK 1.8 but you use:
> >> /jre/java --add-reads ...
> >> The outcome is JVM exit with an error message.
> >> I agree with Herve who also says that  *maven.test.failure.ignore*
> should
> >> not allow the MOJO to throw the exception. It is not a typical JVM
> >> segmentation fault or another JVM crash where we cannot do anything
> about
> >> it, and where the entire build would crash in the command line which
> >> of course means that the build cannot normally be interpreted as BUILD
> >> SUCCESS. So we are still on the same level of failures related to the
> test
> >> purposes.
> >>
> >> On the other hand, Olivier has reopened the issues SUREFIRE-1426 and
> >> SUREFIRE-1681 where the exceptional behavior of the feature is expected.
> >> This is exactly the reason why I closed these tickets several years ago
> and
> >> my proposal was to not to have any exceptions in the feature behavior
> and
> >> the proposal was to introduce a new user property for exact use cases.
> >> The next idea, which comes from two developers, would provide us with
> the
> >> same non exceptional and exact behavior of the user property
> >> *maven.test.failure.ignore* but it would also provide us with new user
> >> property in the case with fine grade control of the build errors, e.g.
> >> *maven.test.jvm.error.ignore*.
> >>
> >
> > with a default of?
> > honestly I just see this new parameter as introducing more complexity in
> an
> > already very complex code and not worth it.
> > again read both issue's comments and my comments.
> > Please try to have a user POV and think about making our users'
> experience
> > more simple.
> >
> > This should be very simple:
> > If surefire forked jvm cannot start it's build error and cannot run any
> > tests, it's a problem users want to know immediately because it can be
> for
> > a lot of reasons: wrong argLine, not enough memory on the system etc...
> >
> > AND AGAIN it is very different from ignoring junit result failures.
> >
> > Try to look at a user point of view and think about what is the use case
> of
> > the property maven.test.failure.ignore=true, I guess 99% of the time,
> users
> > wants to run all their tests (even on a CI with different matrix) so they
> > can collect all the tests results which has runned to see if there is any
> > issue for some combination of thei

Re: [DISCUSS] New Maven Core API for 4.x

[Romain Manni-Bucau]

Hi Guillaume,

+1, also +1 to add a hint in the mojo descriptor if the plugin is mvn4
compatible (version=xxx) to fully isolate it from the maven.core class
realm except the API which will avoid some headache in our tooling and at
runtime!
think it is the way we should priviledge to have a smoother and smaller
code maintenance.

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



Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a écrit :

> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
> 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
>   * fix some problems with designs that do not work well with
> multithreading
>   * offer a way to finally get rid of deprecated code
>   * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
>   * offer an homogeneous and a bit more modern API
>   * completely hide the maven-resolver, so that it can finally upgrade to a
> v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1].  Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api.  The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3].  The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build.  This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
>   * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
>   * release the API, then maven-core supporting the new API
>   * upgrade plugins to the new API, deprecate old components and API
>   * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
>
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
>
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
>
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
>
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Guillaume Nodet]

+1 to upgrade plugins / components


Le dim. 13 mars 2022 à 12:48, Michael Osipov  a écrit :

> Folks,
>
> as you might now we are dragging old luggage over and over with every
> new year. We are making (little) progress with cleansing, skimming and
> updating of our components.
>
> I'll will make a radical proposal I have already discussed privately
> with other fellow committers over Slack:
> Raise the entire baseline to Maven 3.5.4, all of our raises have been
> intermediaries. Reasoning:
> * Maven 3.5.4 is almost 4 old, it is settled
> * Everything before we shouls consider ancient, if you haven't moved
> yet, you will not and it will be your problem.
> * It is the first version which uses Maven Resolver [1]
> * It will free resources to test with previous releases which most don't
> do anyway
> * Maybe this will make it even easier to migrate to the upcoming Maven
> Core API
>
> WDYT?
>
> Michael
>
> PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet

[DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

Hi everyone,

As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
3.5.4" thread, I'd like to start the discussion around it.

Over the past weeks, I've worked on an experimental API for Maven 4.x.
The goals are multiple :
  * fix some problems with designs that do not work well with multithreading
  * offer a way to finally get rid of deprecated code
  * offer a complete API (which would deprecate m-artifact-transfer,
m-dependency-tree)
  * offer an homogeneous and a bit more modern API
  * completely hide the maven-resolver, so that it can finally upgrade to a
v2 with the package renamed without too much disturbance

The goal would be to extract the models and API in a separate project with
a much lower release cycle, as those rarely change, but are currently
released with each version of maven.

The current API can be seen at [1].  Note that the plugins API has also
been included within the new API and the plugin tools have been updated so
that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
new flag has been added to the MojoDescriptor to know if the plugin is
using the old or the new api.  The plugin testing harness tools have been
updated to junit 5 and now provide a few annotations [2] to help writing
plugin tests [3].  The maven-core has been enhanced to support loading
those new v4 plugins along with the v3 ones, which means they can work
side-by-side in the same build.  This is done by implementing the new API
by wrapping the v3 implementation classes (such as MavenSession,
MavenProject, etc...) [4].
I've ported a few plugins such as clean [5], install [6], deploy [7] as a
proof-of-concept that this actually works.

The very rough goal would be to to have multiple phases:
  * continue the work on this API so that it can actually cover all use
cases for plugins, create a new project with the new API and models, make
sure plugins can work correctly with the new API / implementation
  * release the API, then maven-core supporting the new API
  * upgrade plugins to the new API, deprecate old components and API
  * once all plugins have migrated to the new API, switch maven-core
implementation to the new API

I'm eager to hear your thoughts !

[1]
https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
[2]
https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
[3]
https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
[4]
https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
[5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
[6] https://github.com/apache/maven-install-plugin/tree/mvn4/
[7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/

-- 

Guillaume Nodet

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Romain Manni-Bucau]

Le lun. 14 mars 2022 à 08:43, Hervé BOUTEMY  a
écrit :

> Le lundi 14 mars 2022, 08:01:11 CET Maarten Mulders a écrit :
> > Just to clarify: "Raise the entire baseline to Maven 3.5.4" means that
> > the official Maven plugins will only work from Maven Core 3.5.4 onwards?
> yes
>
> > In that case, +1 to move the baseline to 3.5.4.
>
> >
> > Point of concern/question: this may be a breaking change in some cases -
> > how do we communicate that in terms of versioning? Ideally - I'd say - a
> > 3.x plugin works on Maven 3.x, a future 4.x plugin works on Maven 4.x,
> > etc...
> that's why I was proposing to document properly, for example like
>
> https://github.com/git-commit-id/git-commit-id-maven-plugin#plugin-compatibility-with-java
>
> >
> > Also, I agree with Eliotte when it comes to package managers. Even
> > though we do not maintain those ourselves, it's a fact that many people
> > use them to install software on their machines, including Maven. Acting
> > as if it's none of our business would probably equal ignoring those
> users.
> if someone wants to start a page on Maven Site, so everybody can
> contribute by
> proposing a PR, that would be nice
>
> > >> Even more ambitiously, perhaps we should rethink how maven is
> > >> installed. Why should it come from anywhere but Maven Central, and why
> you know what, it's what Maven Wrapper is about :)
>

Just to answer to the "why": cause some distro (several actually) only
accept to build from sources ;).
To also avoid an ambiguity: maven wrapper is not a package manager so it
does not solve the issue (sdkman/chocolatey are for ex).

Question for me is: do we want to do as gradle and bind the build tool to
the project or do we want to keep our nice compatibility which enables most
of dev to have a smooth experience without caring of a lot of details.
I'm indeed for our current philosophy but if it costs too much we should
probably make our distro abuse of our IoC and central to download what is
needed to be compatible maybe?


>
> Regards,
>
> Hervé
>
> >
> >
> > Maarten
> >
> > On 13/03/2022 22:04, Enrico Olivelli wrote:
> > > +1
> > >
> > > Thanks for bringing this up
> > >
> > > Enrico
> > >
> > > Il giorno dom 13 mar 2022 alle ore 20:58 Elliotte Rusty Harold
> > >
> > >  ha scritto:
> > >> What do all the various package managers install? I'm pretty sure I've
> > >> seen one lately whose default was 3.3.1. Debian perhaps?
> > >>
> > >> I think before we make any such move it would make sense to audit what
> > >> people who don't manually install Maven are likely to have. First we
> > >> should raise all those to 3.5.4 or later. Then we can upgrade the
> > >> minimum version.
> > >>
> > >> Even more ambitiously, perhaps we should rethink how maven is
> > >> installed. Why should it come from anywhere but Maven Central, and why
> > >> can't a pom.xml specify the version of Maven itself? All we really
> > >> should install is a very simple bootstrap script. But that's probably
> > >> a discussion for another day. Let's get the package managers
> > >> straightened out first.
> > >>
> > >> On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov 
>
> wrote:
> > >>> Folks,
> > >>>
> > >>> as you might now we are dragging old luggage over and over with every
> > >>> new year. We are making (little) progress with cleansing, skimming
> and
> > >>> updating of our components.
> > >>>
> > >>> I'll will make a radical proposal I have already discussed privately
> > >>> with other fellow committers over Slack:
> > >>> Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > >>> intermediaries. Reasoning:
> > >>> * Maven 3.5.4 is almost 4 old, it is settled
> > >>> * Everything before we shouls consider ancient, if you haven't moved
> > >>> yet, you will not and it will be your problem.
> > >>> * It is the first version which uses Maven Resolver [1]
> > >>> * It will free resources to test with previous releases which most
> don't
> > >>> do anyway
> > >>> * Maybe this will make it even easier to migrate to the upcoming
> Maven
> > >>> Core API
> > >>>
> > >>> WDYT?
> > >>>
> > >>> Michael
> > >>>
> > >>> PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> > >>>
> > >>> [1]
> > >>>
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanu
> > >>> p#MavenEcosystemCleanup-ResolverandMaven
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >> --
> > >> Elliotte Rusty Harold
> > >> elh...@ibiblio.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.or

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Hervé BOUTEMY]

Le lundi 14 mars 2022, 08:01:11 CET Maarten Mulders a écrit :
> Just to clarify: "Raise the entire baseline to Maven 3.5.4" means that
> the official Maven plugins will only work from Maven Core 3.5.4 onwards?
yes

> In that case, +1 to move the baseline to 3.5.4.

> 
> Point of concern/question: this may be a breaking change in some cases -
> how do we communicate that in terms of versioning? Ideally - I'd say - a
> 3.x plugin works on Maven 3.x, a future 4.x plugin works on Maven 4.x,
> etc...
that's why I was proposing to document properly, for example like
https://github.com/git-commit-id/git-commit-id-maven-plugin#plugin-compatibility-with-java

> 
> Also, I agree with Eliotte when it comes to package managers. Even
> though we do not maintain those ourselves, it's a fact that many people
> use them to install software on their machines, including Maven. Acting
> as if it's none of our business would probably equal ignoring those users.
if someone wants to start a page on Maven Site, so everybody can contribute by 
proposing a PR, that would be nice

> >> Even more ambitiously, perhaps we should rethink how maven is
> >> installed. Why should it come from anywhere but Maven Central, and why
you know what, it's what Maven Wrapper is about :)

Regards,

Hervé

> 
> 
> Maarten
> 
> On 13/03/2022 22:04, Enrico Olivelli wrote:
> > +1
> > 
> > Thanks for bringing this up
> > 
> > Enrico
> > 
> > Il giorno dom 13 mar 2022 alle ore 20:58 Elliotte Rusty Harold
> > 
> >  ha scritto:
> >> What do all the various package managers install? I'm pretty sure I've
> >> seen one lately whose default was 3.3.1. Debian perhaps?
> >> 
> >> I think before we make any such move it would make sense to audit what
> >> people who don't manually install Maven are likely to have. First we
> >> should raise all those to 3.5.4 or later. Then we can upgrade the
> >> minimum version.
> >> 
> >> Even more ambitiously, perhaps we should rethink how maven is
> >> installed. Why should it come from anywhere but Maven Central, and why
> >> can't a pom.xml specify the version of Maven itself? All we really
> >> should install is a very simple bootstrap script. But that's probably
> >> a discussion for another day. Let's get the package managers
> >> straightened out first.
> >> 
> >> On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  
wrote:
> >>> Folks,
> >>> 
> >>> as you might now we are dragging old luggage over and over with every
> >>> new year. We are making (little) progress with cleansing, skimming and
> >>> updating of our components.
> >>> 
> >>> I'll will make a radical proposal I have already discussed privately
> >>> with other fellow committers over Slack:
> >>> Raise the entire baseline to Maven 3.5.4, all of our raises have been
> >>> intermediaries. Reasoning:
> >>> * Maven 3.5.4 is almost 4 old, it is settled
> >>> * Everything before we shouls consider ancient, if you haven't moved
> >>> yet, you will not and it will be your problem.
> >>> * It is the first version which uses Maven Resolver [1]
> >>> * It will free resources to test with previous releases which most don't
> >>> do anyway
> >>> * Maybe this will make it even easier to migrate to the upcoming Maven
> >>> Core API
> >>> 
> >>> WDYT?
> >>> 
> >>> Michael
> >>> 
> >>> PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> >>> 
> >>> [1]
> >>> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanu
> >>> p#MavenEcosystemCleanup-ResolverandMaven
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> >> --
> >> Elliotte Rusty Harold
> >> elh...@ibiblio.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: [DISCUSS] Radical Fast Forward to 3.5.4

[Maarten Mulders]

Just to clarify: "Raise the entire baseline to Maven 3.5.4" means that 
the official Maven plugins will only work from Maven Core 3.5.4 onwards? 
In that case, +1 to move the baseline to 3.5.4.


Point of concern/question: this may be a breaking change in some cases - 
how do we communicate that in terms of versioning? Ideally - I'd say - a 
3.x plugin works on Maven 3.x, a future 4.x plugin works on Maven 4.x, 
etc...


Also, I agree with Eliotte when it comes to package managers. Even 
though we do not maintain those ourselves, it's a fact that many people 
use them to install software on their machines, including Maven. Acting 
as if it's none of our business would probably equal ignoring those users.



Maarten

On 13/03/2022 22:04, Enrico Olivelli wrote:

+1

Thanks for bringing this up

Enrico

Il giorno dom 13 mar 2022 alle ore 20:58 Elliotte Rusty Harold
 ha scritto:


What do all the various package managers install? I'm pretty sure I've
seen one lately whose default was 3.3.1. Debian perhaps?

I think before we make any such move it would make sense to audit what
people who don't manually install Maven are likely to have. First we
should raise all those to 3.5.4 or later. Then we can upgrade the
minimum version.

Even more ambitiously, perhaps we should rethink how maven is
installed. Why should it come from anywhere but Maven Central, and why
can't a pom.xml specify the version of Maven itself? All we really
should install is a very simple bootstrap script. But that's probably
a discussion for another day. Let's get the package managers
straightened out first.

On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:


Folks,

as you might now we are dragging old luggage over and over with every
new year. We are making (little) progress with cleansing, skimming and
updating of our components.

I'll will make a radical proposal I have already discussed privately
with other fellow committers over Slack:
Raise the entire baseline to Maven 3.5.4, all of our raises have been
intermediaries. Reasoning:
* Maven 3.5.4 is almost 4 old, it is settled
* Everything before we shouls consider ancient, if you haven't moved
yet, you will not and it will be your problem.
* It is the first version which uses Maven Resolver [1]
* It will free resources to test with previous releases which most don't
do anyway
* Maybe this will make it even easier to migrate to the upcoming Maven
Core API

WDYT?

Michael

PS: I don't even mind 3.6.3 personally, thought I don't this benefit.

[1]
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven

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




--
Elliotte Rusty Harold
elh...@ibiblio.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