Re: Proposal to deprecate Maven 3.0.x

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Eric Lilja
But the proposal was not to deprecate 3.5, but anything below (since 3.5
was when the resolver was introduced)?

- Eric L

On Thu, Apr 16, 2020 at 11:08 AM Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Tibor, technically you are likely right but deprecating is not only
> technical, i'd say it is only 10% of the choice (even if it is what
> triggers the discussion).
> The biggest part for me is how it affects users.
> 3.5.x is only 3 years old so I think it is too early to deprecate it (guess
> we should target at least 5 years of support) so I think 3.3 can't be
> deprecated today but maybe in 1 or 2 years.
> That said we can stop supporting 3.3 for new version of plugins and only be
> reactive to backport a fix if needed (it is quite rare I think). This way
> we can move forward and not send a negative message for enterprises.
> In other words: we support >= 3.3 but plugin upgrades  can target only >
> 3.5.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 16 avr. 2020 à 10:41, Tibor Digana <[hidden email]> a
> écrit :
>
> > The Eclipse Aether looks like a strong argument.
> > If any user would open an issue to provide a fix on the top of Eclipse
> > Aether then we say 'no' already today in 3.7.0.
> > So the user has to switch to 3.5.0+ which would end up for him as the
> > same as deprecating 3.0.x - 3.3.x.
> > I know that it is a big extend, i understand that but this is
> > currently the outcome of my analysis.
> >
> > I don't know what you think about this view.
> >
> > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY <[hidden email]>
> > wrote:
> > >
> > > +1 to deprecate 3.0.x
> > >
> > > TLDR; no need to deprecate Eclipse Aether, which would mean deprecating
> > also
> > > 3.1.x, 3.2.x and 3.3.x
> > >
> > > details:
> > > "deprecate everything before the maven-resolver import" would mean
> > deprecating
> > > up to 3.3.x [1]
> > >
> > > Given that maven-resolver has exactly the same API as Eclipse Aether
> (in
> > > org.eclipse.aether java package) but just a change in Maven coordinates
> > (that
> > > are all filtered by Maven core class loading, then not really an
> issue),
> > I'm
> > > not convinced this is absolutely necessary to go to that extend
> > >
> > > what is really useful is to deprecate anything that is not in
> > > org.eclipse.aether Java package, because it is a nightmare in terms of
> > Java
> > > code compatibility: this means deprecating 3.0.x only [2], given the
> > switch to
> > > Eclipse Aether has been done in 3.1.0 [3]
> > > And, for the record, the switch to Maven Artifact Resolver has been
> done
> > in
> > > 3.5.0 [4]
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
> > >
> > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
> > >
> > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
> > >
> > > [4]
> > https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
> > >
> > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > > > +100
> > > >
> > > > I would deprecate everything before the maven-resolver import back to
> > the
> > > > project while you are at it. Not sure exact version but 3.1x would
> > > > definitely on that list as well. Maybe also 3.2x
> > > >
> > > > Manfred
> > > >
> > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > > > Some users still use Maven 3.0.5 and they require a support for
> > > > > compatibility reasons between nowadays Maven plugins and the Maven
> > > > > 3.0.x.
> > > > >
> > > > > We have a couple of reasons to deprecate this version (JSR-330,
> > > > > Components injection, Logger) and we have discussed this issue in
> > > > > https://github.com/apache/maven-surefire/pull/274
> > > > >
> > > > > Let's discuss it.
> > > > >
> > > > > Cheers
> > > > > Tibor17
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Eric Lilja
Well, it's been supported for five years now, which was the threshold you
mentioned to be reasonable.

- Eric L

On Thu, Apr 16, 2020 at 11:29 AM Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Eric, point is that we can't deprecate 3.3 too IMHO.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 16 avr. 2020 à 11:18, Eric Lilja <[hidden email]> a écrit :
>
> > But the proposal was not to deprecate 3.5, but anything below (since 3.5
> > was when the resolver was introduced)?
> >
> > - Eric L
> >
> > On Thu, Apr 16, 2020 at 11:08 AM Romain Manni-Bucau <
> [hidden email]
> > >
> > wrote:
> >
> > > Hi Tibor, technically you are likely right but deprecating is not only
> > > technical, i'd say it is only 10% of the choice (even if it is what
> > > triggers the discussion).
> > > The biggest part for me is how it affects users.
> > > 3.5.x is only 3 years old so I think it is too early to deprecate it
> > (guess
> > > we should target at least 5 years of support) so I think 3.3 can't be
> > > deprecated today but maybe in 1 or 2 years.
> > > That said we can stop supporting 3.3 for new version of plugins and
> only
> > be
> > > reactive to backport a fix if needed (it is quite rare I think). This
> way
> > > we can move forward and not send a negative message for enterprises.
> > > In other words: we support >= 3.3 but plugin upgrades  can target only
> >
> > > 3.5.
> > >
> > > Wdyt?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le jeu. 16 avr. 2020 à 10:41, Tibor Digana <[hidden email]> a
> > > écrit :
> > >
> > > > The Eclipse Aether looks like a strong argument.
> > > > If any user would open an issue to provide a fix on the top of
> Eclipse
> > > > Aether then we say 'no' already today in 3.7.0.
> > > > So the user has to switch to 3.5.0+ which would end up for him as the
> > > > same as deprecating 3.0.x - 3.3.x.
> > > > I know that it is a big extend, i understand that but this is
> > > > currently the outcome of my analysis.
> > > >
> > > > I don't know what you think about this view.
> > > >
> > > > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY <[hidden email]
> >
> > > > wrote:
> > > > >
> > > > > +1 to deprecate 3.0.x
> > > > >
> > > > > TLDR; no need to deprecate Eclipse Aether, which would mean
> > deprecating
> > > > also
> > > > > 3.1.x, 3.2.x and 3.3.x
> > > > >
> > > > > details:
> > > > > "deprecate everything before the maven-resolver import" would mean
> > > > deprecating
> > > > > up to 3.3.x [1]
> > > > >
> > > > > Given that maven-resolver has exactly the same API as Eclipse
> Aether
> > > (in
> > > > > org.eclipse.aether java package) but just a change in Maven
> > coordinates
> > > > (that
> > > > > are all filtered by Maven core class loading, then not really an
> > > issue),
> > > > I'm
> > > > > not convinced this is absolutely necessary to go to that extend
> > > > >
> > > > > what is really useful is to deprecate anything that is not in
> > > > > org.eclipse.aether Java package, because it is a nightmare in terms
> > of
> > > > Java
> > > > > code compatibility: this means deprecating 3.0.x only [2], given
> the
> > > > switch to
> > > > > Eclipse Aether has been done in 3.1.0 [3]
> > > > > And, for the record, the switch to Maven Artifact Resolver has been
> > > done
> > > > in
> > > > > 3.5.0 [4]
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
> > > > >
> > > > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
> > > > >
> > > > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
> > > > >
> > > > > [4]
> > > >
> https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
> > > > >
> > > > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > > > > > +100
> > > > > >
> > > > > > I would deprecate everything before the maven-resolver import
> back
> > to
> > > > the
> > > > > > project while you are at it. Not sure exact version but 3.1x
> would
> > > > > > definitely on that list as well. Maybe also 3.2x
> > > > > >
> > > > > > Manfred
> > > > > >
> > > > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > > > > > Some users still use Maven 3.0.5 and they require a support for
> > > > > > > compatibility reasons between nowadays Maven plugins and the
> > Maven
> > > > > > > 3.0.x.
> > > > > > >
> > > > > > > We have a couple of reasons to deprecate this version (JSR-330,
> > > > > > > Components injection, Logger) and we have discussed this issue
> in
> > > > > > > https://github.com/apache/maven-surefire/pull/274
> > > > > > >
> > > > > > > Let's discuss it.
> > > > > > >
> > > > > > > Cheers
> > > > > > > Tibor17
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Karl Heinz Marbaise-3
In reply to this post by Eric Lilja
Hi,

On 16.04.20 12:22, Hervé BOUTEMY wrote:

> we're back at defining what our community support on every Maven parts means
>
> to me, support for Maven core releases not only means that we would release
> security bugfix if security issues were found (very low probability), but more
> that we do *extra efforts on plugins to be checked for compatibility*
>
> Maven 3.0.x costs efforts for plugins compatibility, because of the old very
> specific API
> starting with 3.1.x, API is org.eclipse.aether.*: AFAIK, no complexity to have
> plugins compatibility
>
> that's why "deprecating Maven 3.0.x" to me is a reasonable choice (lower
> community efforts with minimal users impact) that will concretely mean "produce
> plugins with Maven 3.1 as minimum", cleaning old code and tests for 3.0.x
> compatibility

Yes that makes several parts easier...

Kind regards
Karl Heinz Marbaise

>
> Regards,
>
> Hervé
>
> Le jeudi 16 avril 2020, 10:41:23 CEST Tibor Digana a écrit :
>> The Eclipse Aether looks like a strong argument.
>> If any user would open an issue to provide a fix on the top of Eclipse
>> Aether then we say 'no' already today in 3.7.0.
>> So the user has to switch to 3.5.0+ which would end up for him as the
>> same as deprecating 3.0.x - 3.3.x.
>> I know that it is a big extend, i understand that but this is
>> currently the outcome of my analysis.
>>
>> I don't know what you think about this view.
>>
>> On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY <[hidden email]> wrote:
>>> +1 to deprecate 3.0.x
>>>
>>> TLDR; no need to deprecate Eclipse Aether, which would mean deprecating
>>> also 3.1.x, 3.2.x and 3.3.x
>>>
>>> details:
>>> "deprecate everything before the maven-resolver import" would mean
>>> deprecating up to 3.3.x [1]
>>>
>>> Given that maven-resolver has exactly the same API as Eclipse Aether (in
>>> org.eclipse.aether java package) but just a change in Maven coordinates
>>> (that are all filtered by Maven core class loading, then not really an
>>> issue), I'm not convinced this is absolutely necessary to go to that
>>> extend
>>>
>>> what is really useful is to deprecate anything that is not in
>>> org.eclipse.aether Java package, because it is a nightmare in terms of
>>> Java
>>> code compatibility: this means deprecating 3.0.x only [2], given the
>>> switch to Eclipse Aether has been done in 3.1.0 [3]
>>> And, for the record, the switch to Maven Artifact Resolver has been done
>>> in
>>> 3.5.0 [4]
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
>>>
>>> [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
>>>
>>> [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
>>>
>>> [4] https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
>>>
>>> Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
>>>> +100
>>>>
>>>> I would deprecate everything before the maven-resolver import back to
>>>> the
>>>> project while you are at it. Not sure exact version but 3.1x would
>>>> definitely on that list as well. Maybe also 3.2x
>>>>
>>>> Manfred
>>>>
>>>> Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
>>>>> Some users still use Maven 3.0.5 and they require a support for
>>>>> compatibility reasons between nowadays Maven plugins and the Maven
>>>>> 3.0.x.
>>>>>
>>>>> We have a couple of reasons to deprecate this version (JSR-330,
>>>>> Components injection, Logger) and we have discussed this issue in
>>>>> https://github.com/apache/maven-surefire/pull/274
>>>>>
>>>>> Let's discuss it.
>>>>>
>>>>> Cheers
>>>>> Tibor17
>>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Elliotte Rusty Harold
In reply to this post by Eric Lilja
Have we documented anywhere exactly what's going on with aether? This
was a huge stumbling block when I first started working with the
Mavena and Aether code a couple of years ago. There was so much old
and out of date contradictory information out there on different web
sites, and no way I could figure out to tell which was the most up to
date. I'm still not sure I understand which is right. I thought it was
org.eclipse.aether:aether, but from this thread it sounds like we
should be getting those from org.apache.maven.resolver:maven-resolver
instead?

On Thu, Apr 16, 2020 at 2:52 AM Hervé BOUTEMY <[hidden email]> wrote:

>
> +1 to deprecate 3.0.x
>
> TLDR; no need to deprecate Eclipse Aether, which would mean deprecating also
> 3.1.x, 3.2.x and 3.3.x
>
> details:
> "deprecate everything before the maven-resolver import" would mean deprecating
> up to 3.3.x [1]
>
> Given that maven-resolver has exactly the same API as Eclipse Aether (in
> org.eclipse.aether java package) but just a change in Maven coordinates (that
> are all filtered by Maven core class loading, then not really an issue), I'm
> not convinced this is absolutely necessary to go to that extend
>
> what is really useful is to deprecate anything that is not in
> org.eclipse.aether Java package, because it is a nightmare in terms of Java
> code compatibility: this means deprecating 3.0.x only [2], given the switch to
> Eclipse Aether has been done in 3.1.0 [3]
> And, for the record, the switch to Maven Artifact Resolver has been done in
> 3.5.0 [4]
>
> Regards,
>
> Hervé
>
> [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
>
> [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
>
> [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
>
> [4] https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
>
> Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > +100
> >
> > I would deprecate everything before the maven-resolver import back to the
> > project while you are at it. Not sure exact version but 3.1x would
> > definitely on that list as well. Maybe also 3.2x
> >
> > Manfred
> >
> > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > Some users still use Maven 3.0.5 and they require a support for
> > > compatibility reasons between nowadays Maven plugins and the Maven
> > > 3.0.x.
> > >
> > > We have a couple of reasons to deprecate this version (JSR-330,
> > > Components injection, Logger) and we have discussed this issue in
> > > https://github.com/apache/maven-surefire/pull/274
> > >
> > > Let's discuss it.
> > >
> > > Cheers
> > > Tibor17
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Hervé BOUTEMY
In reply to this post by Eric Lilja
Le jeudi 16 avril 2020, 13:01:31 CEST Elliotte Rusty Harold a écrit :
> On Thu, Apr 16, 2020 at 6:53 AM Tibor Digana <[hidden email]> wrote:
> > I agree with Herve to start with deprecating 3.0.x.
> > And what sounds nice to me is producing the plugins with 3.1 as
> > minimum and clearing the old code and tests for 3.0.x.
> > This sounds like a plan for the community.
>
> I concur with this and feel like we actually made this decision
> already, though I'd have to dig through the archives to find the exact
> message.
perhaps we should write some statement somewhere on
https://maven.apache.org/developers/index.html

>
> What do we mean by "deprecating"? In Java world I think of deprecating
> as adding @Deprecated to a method or class, which doesn't work here.
> Are we talking about removing support for Maven 3.0.x in future work?
> That sounds good to me.
upgrading Maven Version Prerequisite for plugins to 3.1 instead of 3.0
https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html

>
> I'm still working on removing references to **Maven 2.x** and even 1.x
> from the website. Once that's done perhaps we can remove 3.0.x as
> well.
sure, cleanup at every level including documentation can be useful
thank you




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to deprecate Maven 3.0.x

Hervé BOUTEMY
In reply to this post by Elliotte Rusty Harold
Le jeudi 16 avril 2020, 13:06:31 CEST Elliotte Rusty Harold a écrit :
> Have we documented anywhere exactly what's going on with aether? This
> was a huge stumbling block when I first started working with the
> Mavena and Aether code a couple of years ago. There was so much old
> and out of date contradictory information out there on different web
> sites, and no way I could figure out to tell which was the most up to
> date. I'm still not sure I understand which is right. I thought it was
> org.eclipse.aether:aether, but from this thread it sounds like we
> should be getting those from org.apache.maven.resolver:maven-resolver
> instead?
our target is https://maven.apache.org/resolver/
which means:
- Maven coordinates are org.apache.maven.resolver:maven-resolver-* (which
replace former org.eclipse.aether:aether-*)
- java API in the artifacts remain org.eclipse.aether, then no code
compatibility issue between code in different coordinates
see https://maven.apache.org/resolver/apidocs/index.html

and as described previously, Maven core filters out "old Aether" Maven
coordinates:
https://maven.apache.org/ref/3.6.3/maven-core/core-extensions.html
Then plugins should import org.eclipse.aether to provide best compatibility
starting with Maven 3.1.x (which did not know about Maven Resolver new
coordinates)

HTH

Hervé

>
> On Thu, Apr 16, 2020 at 2:52 AM Hervé BOUTEMY <[hidden email]> wrote:
> > +1 to deprecate 3.0.x
> >
> > TLDR; no need to deprecate Eclipse Aether, which would mean deprecating
> > also 3.1.x, 3.2.x and 3.3.x
> >
> > details:
> > "deprecate everything before the maven-resolver import" would mean
> > deprecating up to 3.3.x [1]
> >
> > Given that maven-resolver has exactly the same API as Eclipse Aether (in
> > org.eclipse.aether java package) but just a change in Maven coordinates
> > (that are all filtered by Maven core class loading, then not really an
> > issue), I'm not convinced this is absolutely necessary to go to that
> > extend
> >
> > what is really useful is to deprecate anything that is not in
> > org.eclipse.aether Java package, because it is a nightmare in terms of
> > Java
> > code compatibility: this means deprecating 3.0.x only [2], given the
> > switch to Eclipse Aether has been done in 3.1.0 [3]
> > And, for the record, the switch to Maven Artifact Resolver has been done
> > in
> > 3.5.0 [4]
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
> >
> > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
> >
> > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
> >
> > [4] https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
> >
> > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > > +100
> > >
> > > I would deprecate everything before the maven-resolver import back to
> > > the
> > > project while you are at it. Not sure exact version but 3.1x would
> > > definitely on that list as well. Maybe also 3.2x
> > >
> > > Manfred
> > >
> > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > > Some users still use Maven 3.0.5 and they require a support for
> > > > compatibility reasons between nowadays Maven plugins and the Maven
> > > > 3.0.x.
> > > >
> > > > We have a couple of reasons to deprecate this version (JSR-330,
> > > > Components injection, Logger) and we have discussed this issue in
> > > > https://github.com/apache/maven-surefire/pull/274
> > > >
> > > > Let's discuss it.
> > > >
> > > > Cheers
> > > > Tibor17
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]