Re: Proposal to deprecate Maven 3.0.x

[Manfred Moser]

We nearly never backport fixes. Support just means that there is a chance it 
still works.. realistically we only support latest release..

Manfred

Tibor Digana wrote on 2020-04-16 13:30 (GMT -07:00):

> I want to ask a question regarding the maintenance of old minor
> versions because i've started missing the right meaning of what
> deprecation of Maven (not plugins) means.
> Due to now we are at Maven 3.6.3 we support the bugfixing of 3.6.x
> family. But AFAIK we won't suppor bugfixing of 3.5 families and
> earlier. Would it mean that all versions prior to 3.6 could be
> deprecated so? If they are not deprecated then the users may expect
> bugfixing.
> 
> On Thu, Apr 16, 2020 at 9:06 PM Robert Scholte  wrote:
>>
>> The answer is 3.1.0. It is way more easier to say "plugins are Maven 3.1 or
>> 3.1.x compatible".
>> The APIs are the same, there should be no impact.
>> So compile with 3.1.0 dependencies, run on Jenkins with 3.1.1 (as being the
>> last 3.1.x release, like we do with all 3.x.latest)
>>
>> We had the same discussion when talking about 3.0 or 3.0.5, with the result:
>> plugins should be Maven 3 compatible.
>>
>> Also be careful with the wording:
>> we're not deprecating Maven 3.0.x, but plugins will require Maven 3.1 (or 
>> drop
>> Maven 3.0 SUPPORT for plugins)
>> A title like this is very misleading.
>>
>> Robert
>> On 16-4-2020 13:01:39, Sylwester Lachiewicz  wrote:
>> So next quick question - should be 3.1.0 or 3.1.1 - last and recommend
>> version for Java 5?
>>
>> Sylwester
>>
>> czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana
>> napisał:
>>
>> > 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.
>> >
>> > On Thu, Apr 16, 2020 at 12:22 PM 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
>> > >
>> > > 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
>> > 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-alp

Re: Proposal to deprecate Maven 3.0.x

[Manfred Moser]

All features are already in Maven Resolver .. 

We should deprecate  everything before 3.5.0 imho

Or if really necessary everything before 3.2.5

Gabriel Belingueres wrote on 2020-04-16 17:35 (GMT -07:00):

> +1 to deprecate 3.0.x to get rid of Sonatype Aether, which would
> considerably simplify the dependency handling code base.
> 
> Not my use case, but,just to put it over the table, we should check the
> Eclipse Aether New and Noteworthy page [1] to see if there is some
> particular requirement over aether library that we want to take for granted.
> 
> I've looked for each aether version used by maven and I came up with the
> following list:
> 
> "3.0.0" <-- Sonatype Aether 1.7
> "3.0.1" <-- Sonatype Aether 1.8
> "3.0.2" <-- Sonatype Aether 1.9
> "3.0.3" <-- Sonatype Aether 1.11
> "3.0.4" <-- Sonatype Aether 1.13.1
> "3.0.5" <-- Sonatype Aether 1.13.1
> 
> "3.1.0" <-- Eclipse Aether 0.9.0M2
> "3.1.1" <-- Eclipse Aether 0.9.0M2
> "3.2.1" <-- Eclipse Aether 0.9.0M2
> "3.2.2" <-- Eclipse Aether 0.9.0M2
> "3.2.3" <-- Eclipse Aether 0.9.0M2
> 
> "3.2.5" <-- Eclipse Aether 1.0.0.v20140518
> 
> "3.3.1" <-- Eclipse Aether 1.0.2.v20150114
> "3.3.3" <-- Eclipse Aether 1.0.2.v20150114
> "3.3.9" <-- Eclipse Aether 1.0.2.v20150114
> 
> "3.5.0" <-- Maven Resolver 1.0.3
> 
> "3.5.2" <-- Maven Resolver 1.1.0
> 
> "3.5.3" <-- Maven Resolver 1.1.1
> "3.5.4" <-- Maven Resolver 1.1.1
> 
> "3.6.0" <-- Maven Resolver 1.3.1
> 
> "3.6.1" <-- Maven Resolver 1.3.3
> 
> "3.6.2" <-- Maven Resolver 1.4.1
> "3.6.3" <-- Maven Resolver 1.4.1
> 
> 
> so for example, let's say if it is really important that the CollectResult
> class keeps the detected dependency cycles (0.0.9-M4) then we should think
> in deprecating until maven 3.2.3.
> 
> Again, not my use case. I'm fine with deprecating 3.0.x.
> 
> Best regards,
> Gabriel
> 
> [1] https://wiki.eclipse.org/Aether/New_and_Noteworthy
> 
> El mié., 15 de abr. de 2020 a la(s) 17:39, Tibor Digana (
> tibordig...@apache.org) escribió:
> 
>> 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: 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: Proposal to deprecate Maven 3.0.x

[Gabriel Belingueres]

+1 to deprecate 3.0.x to get rid of Sonatype Aether, which would
considerably simplify the dependency handling code base.

Not my use case, but,just to put it over the table, we should check the
Eclipse Aether New and Noteworthy page [1] to see if there is some
particular requirement over aether library that we want to take for granted.

I've looked for each aether version used by maven and I came up with the
following list:

"3.0.0" <-- Sonatype Aether 1.7
"3.0.1" <-- Sonatype Aether 1.8
"3.0.2" <-- Sonatype Aether 1.9
"3.0.3" <-- Sonatype Aether 1.11
"3.0.4" <-- Sonatype Aether 1.13.1
"3.0.5" <-- Sonatype Aether 1.13.1

"3.1.0" <-- Eclipse Aether 0.9.0M2
"3.1.1" <-- Eclipse Aether 0.9.0M2
"3.2.1" <-- Eclipse Aether 0.9.0M2
"3.2.2" <-- Eclipse Aether 0.9.0M2
"3.2.3" <-- Eclipse Aether 0.9.0M2

"3.2.5" <-- Eclipse Aether 1.0.0.v20140518

"3.3.1" <-- Eclipse Aether 1.0.2.v20150114
"3.3.3" <-- Eclipse Aether 1.0.2.v20150114
"3.3.9" <-- Eclipse Aether 1.0.2.v20150114

"3.5.0" <-- Maven Resolver 1.0.3

"3.5.2" <-- Maven Resolver 1.1.0

"3.5.3" <-- Maven Resolver 1.1.1
"3.5.4" <-- Maven Resolver 1.1.1

"3.6.0" <-- Maven Resolver 1.3.1

"3.6.1" <-- Maven Resolver 1.3.3

"3.6.2" <-- Maven Resolver 1.4.1
"3.6.3" <-- Maven Resolver 1.4.1


so for example, let's say if it is really important that the CollectResult
class keeps the detected dependency cycles (0.0.9-M4) then we should think
in deprecating until maven 3.2.3.

Again, not my use case. I'm fine with deprecating 3.0.x.

Best regards,
Gabriel

[1] https://wiki.eclipse.org/Aether/New_and_Noteworthy

El mié., 15 de abr. de 2020 a la(s) 17:39, Tibor Digana (
tibordig...@apache.org) escribió:

> 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[ANN] Maven Fluido Skin 1.9 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Fluido Skin, version 1.9.


https://maven.apache.org/skins/maven-fluido-skin/

You should specify the version in your project's site configuration:


  org.apache.maven.skins
  maven-fluido-skin
  1.9



Release Notes - Maven Fluido Skin - Version 1.9

** Sub-task
* [MSKINS-105] - Provide alt text for all images

** Bug
* [MSKINS-157] - Fluido 1.8 has garbled footer

** Improvement
* [MSKINS-160] - Broken links to JIRA
* [MSKINS-161] - Upgrade Facebook Like button integration
* [MSKINS-162] - Add GitHub Action to confirm PR build

** Task
* [MSKINS-102] - Make Fluido-generated pages pass W3 HTML5 
Validation Service


** Dependency upgrade
* [MSKINS-163] - Upgrade to parent POM 34
* [MSKINS-164] - Upgrade to Maven Invoker Plugin 3.2.1


Enjoy,

-The Apache Maven team

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

[RESULT] [VOTE] Release Maven Fluido Skin version 1.9

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Sylwester Lachiewicz, Tibor Digana, Karl Heiz Marbaise

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file and add this release the board report.


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

Re: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

I want to ask a question regarding the maintenance of old minor
versions because i've started missing the right meaning of what
deprecation of Maven (not plugins) means.
Due to now we are at Maven 3.6.3 we support the bugfixing of 3.6.x
family. But AFAIK we won't suppor bugfixing of 3.5 families and
earlier. Would it mean that all versions prior to 3.6 could be
deprecated so? If they are not deprecated then the users may expect
bugfixing.

On Thu, Apr 16, 2020 at 9:06 PM Robert Scholte  wrote:
>
> The answer is 3.1.0. It is way more easier to say "plugins are Maven 3.1 or 
> 3.1.x compatible".
> The APIs are the same, there should be no impact.
> So compile with 3.1.0 dependencies, run on Jenkins with 3.1.1 (as being the 
> last 3.1.x release, like we do with all 3.x.latest)
>
> We had the same discussion when talking about 3.0 or 3.0.5, with the result: 
> plugins should be Maven 3 compatible.
>
> Also be careful with the wording:
> we're not deprecating Maven 3.0.x, but plugins will require Maven 3.1 (or 
> drop Maven 3.0 SUPPORT for plugins)
> A title like this is very misleading.
>
> Robert
> On 16-4-2020 13:01:39, Sylwester Lachiewicz  wrote:
> So next quick question - should be 3.1.0 or 3.1.1 - last and recommend
> version for Java 5?
>
> Sylwester
>
> czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana
> napisał:
>
> > 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.
> >
> > On Thu, Apr 16, 2020 at 12:22 PM 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
> > >
> > > 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
> > 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
> > > > > > d

Re: Proposal to deprecate Maven 3.0.x

[Gary Gregory]

On Thu, Apr 16, 2020 at 3:04 PM Sesterhenn, Jörg 
wrote:

> Hi, please let me give you a users perspective:
>
> 1) deprecate *every* version that is not likely to get an important
> issue (even if it only concerns a core plugin) fixed timely - no matter
> how old it is. Anything else is lying to yourself and your users about
> your capability. There is no shame in not beeing able to support a
> version after the next one was released given that this support is not
> beeing paid for.
>
> 2) think about (and communicate) support cycles before you introduce
> breaking changes. Only provide *one *LTS-Version if you feel you can
> handle that commitment.
>
> 4) try to support usecases rather than plugins - if something old needs
> to be droped you can provide a new solution instead of dragging old
> stuff with you
>
> 5) try and do contnuous delivery. If you can not because of the way that
> plugins are kept apart from maven try at least to introduce regular
> releasetrains with small changesets. maybe eclipse could step in and
> help with that ?
>
> I believe all this would help users and developers to deal with changes
> in a more professional way. This could also free up time to introduce
> new concepts and features that are long overdue.
>

Nice message!

Gary


>
> Regards
>
> Jörg Sesterhenn
>
> --
> Jörg Sesterhenn
> Referent
>
> Debeka Krankenversicherungsverein a. G.
> Debeka Lebensversicherungsverein a. G.
> Debeka Allgemeine Versicherung AG
> Debeka Pensionskasse AG
> Debeka Bausparkasse AG
>
> Abteilung IT-Grundlagen & -Engineering
> IT-Prozesse und Automatisierung (IE/P)
> 56058 Koblenz
>
> Telefon: (02 61) 4 98 – 14 55
> Telefax: (02 61) 4 98 – 15 41
>
> E-Mail: joerg.sesterh...@debeka.de
> Internet: www.debeka.de
>
> Besuchen Sie uns auch in sozialen Netzwerken.
> Unsere Adressen finden Sie hier: www.debeka.de/socialmedia
>
> Pflichtangaben der Debeka-Unternehmen
> gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben
>
>

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Robert Scholte]

For MGPG-59[1] the version had to be parsed because of a feature that only 
works for gpg2.

Robert


[1] https://issues.apache.org/jira/browse/MGPG-59

On 15-4-2020 23:12:47, Tibor Digana  wrote:
Why this plugin has been working for many years and with the same gpg
installation?
There has to be a change in the comparator of versions according to
the stacktrace. What other explanation?
I did not change anything on my PC. Still the same set of tools.

On Wed, Apr 15, 2020 at 11:07 PM Robert Scholte wrote:
>
> gpg --version
>
> gpg (GnuPG) 2.2.15
> libgcrypt 1.8.4
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> I've asked INFRA to install gpg on Jenkins, so for about a year both Ubuntu 
> and Windows are covered.
>
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/INFRA-18014
> On 15-4-2020 22:16:35, Hervé BOUTEMY wrote:
> questions to Windows users:
> - what GPG distribution do you use, that does not make the plugin fail?
> - is this issue worth dropping the release?
>
> Regards,
>
> Hervé
>
> Le mercredi 15 avril 2020, 21:25:11 CEST Tibor Digana a écrit :
> > Sorry my -1 due to all integration tests have failed with the following
> > errors:
> >
> > Caused by: java.lang.IllegalArgumentException: Can't parse version of
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > at org.apache.maven.plugins.gpg.GpgVersion.compareTo(GpgVersion.java:60)
> > at org.apache.maven.plugins.gpg.GpgVersion.isBefore(GpgVersion.java:101) at
> > org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.j
> > ava:89) at
> > org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact
> > (AbstractGpgSigner.java:203) at
> > org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMoj
> > o.java:178) at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
> > luginManager.java:134)
> >
> > The version on the command line:
> >
> > $ gpg --version
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > libgcrypt 1.6.2
> > Copyright (C) 2013 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > This is free software: you are free to
> > change and redistribute it. There is NO WARRANTY, to the extent permitted
> > by law.
> >
> > On Sun, Apr 12, 2020 at 2:50 PM Hervé BOUTEMY wrote:
> > > Hi,
> > >
> > > We solved 13 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&;
> > > version=12330781&styleName=Text
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1563/
> > > https://repository.apache.org/content/repositories/maven-1563/org/apache/m
> > > aven/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.
> > > zip
> > >
> > > Source release checksum(s):
> > > maven-gpg-plugin-3.0.0-source-release.zip sha512:
> > > 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b5
> > > 4209a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> > >
> > > Staging site:
> > > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > > -
> > > 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
>


--
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Robert Scholte]

The answer is 3.1.0. It is way more easier to say "plugins are Maven 3.1 or 
3.1.x compatible".
The APIs are the same, there should be no impact.
So compile with 3.1.0 dependencies, run on Jenkins with 3.1.1 (as being the 
last 3.1.x release, like we do with all 3.x.latest)

We had the same discussion when talking about 3.0 or 3.0.5, with the result: 
plugins should be Maven 3 compatible.

Also be careful with the wording:
we're not deprecating Maven 3.0.x, but plugins will require Maven 3.1 (or drop 
Maven 3.0 SUPPORT for plugins)
A title like this is very misleading.

Robert
On 16-4-2020 13:01:39, Sylwester Lachiewicz  wrote:
So next quick question - should be 3.1.0 or 3.1.1 - last and recommend
version for Java 5?

Sylwester

czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana
napisał:

> 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.
>
> On Thu, Apr 16, 2020 at 12:22 PM 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
> >
> > 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
> 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
> > > > > >
> > > > > >
> ---

Proposal to deprecate Maven 3.0.x

[Sesterhenn , Jörg]

Hi, please let me give you a users perspective:

1) deprecate *every* version that is not likely to get an important 
issue (even if it only concerns a core plugin) fixed timely - no matter 
how old it is. Anything else is lying to yourself and your users about 
your capability. There is no shame in not beeing able to support a 
version after the next one was released given that this support is not 
beeing paid for.


2) think about (and communicate) support cycles before you introduce 
breaking changes. Only provide *one *LTS-Version if you feel you can 
handle that commitment.


4) try to support usecases rather than plugins - if something old needs 
to be droped you can provide a new solution instead of dragging old 
stuff with you


5) try and do contnuous delivery. If you can not because of the way that 
plugins are kept apart from maven try at least to introduce regular 
releasetrains with small changesets. maybe eclipse could step in and 
help with that ?


I believe all this would help users and developers to deal with changes 
in a more professional way. This could also free up time to introduce 
new concepts and features that are long overdue.


Regards

Jörg Sesterhenn

--
Jörg Sesterhenn
Referent

Debeka Krankenversicherungsverein a. G.
Debeka Lebensversicherungsverein a. G.
Debeka Allgemeine Versicherung AG
Debeka Pensionskasse AG
Debeka Bausparkasse AG

Abteilung IT-Grundlagen & -Engineering
IT-Prozesse und Automatisierung (IE/P)
56058 Koblenz

Telefon: (02 61) 4 98 – 14 55
Telefax: (02 61) 4 98 – 15 41

E-Mail: joerg.sesterh...@debeka.de
Internet: www.debeka.de

Besuchen Sie uns auch in sozialen Netzwerken.
Unsere Adressen finden Sie hier: www.debeka.de/socialmedia

Pflichtangaben der Debeka-Unternehmen
gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben

Proposal to deprecate Maven 3.0.x

[Sesterhenn , Jörg]

Hi, please let me give you a users perspective:

1) deprecate *every* version that is not likely to get an important 
issue (even if it only concerns a core plugin) fixed timely - no matter 
how old it is. Anything else is lying to yourself and your users about 
your capability. There is no shame in not beeing able to support a 
version after the next one was released given that this support is not 
beeing paid for.


2) think about (and communicate) support cycles before you introduce 
breaking changes. Only provide *one *LTS-Version if you feel you can 
handle that commitment.


4) try to support usecases rather than plugins - if something old needs 
to be droped you can provide a new solution instead of dragging old 
stuff with you


5) try and do contnuous delivery. If you can not because of the way that 
plugins are kept apart from maven try at least to introduce regular 
releasetrains with small changesets. maybe eclipse could step in and 
help with that ?


I believe all this would help users and developers to deal with changes 
in a more professional way. This could also free up time to introduce 
new concepts and features that are long overdue.


Regards

Jörg Sesterhenn

--
Jörg Sesterhenn
Referent

Debeka Krankenversicherungsverein a. G.
Debeka Lebensversicherungsverein a. G.
Debeka Allgemeine Versicherung AG
Debeka Pensionskasse AG
Debeka Bausparkasse AG

Abteilung IT-Grundlagen & -Engineering
IT-Prozesse und Automatisierung (IE/P)
56058 Koblenz

Telefon: (02 61) 4 98 – 14 55
Telefax: (02 61) 4 98 – 15 41

E-Mail: joerg.sesterh...@debeka.de
Internet: www.debeka.de

Besuchen Sie uns auch in sozialen Netzwerken.
Unsere Adressen finden Sie hier: www.debeka.de/socialmedia

Pflichtangaben der Debeka-Unternehmen
gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben

Re: [VOTE] Release Maven Fluido Skin version 1.9

[Michael Osipov]

Am 2020-04-13 um 23:07 schrieb Michael Osipov:

Hi,

We solved 8 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346750&styleName=Text&projectId=12317926 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSKINS%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Fluido%20Skin%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC 



Staging repo:
https://repository.apache.org/content/repositories/maven-1564/
https://repository.apache.org/content/repositories/maven-1564/org/apache/maven/skins/maven-fluido-skin/1.9/maven-fluido-skin-1.9-source-release.zip 



Source release checksum(s):
maven-fluido-skin-1.9-source-release.zip
sha512: 
32430d431d0f578e448bd276326078a8b9acea6a5c028d1a68e0951c583ae3d3a13eaaa690446f9da593d4d3e59dae1ff843ca68f1e3b0b46596555a018810b8 



Staging site:
https://maven.apache.org/components/skins-archives/maven-fluido-skin-LATEST/ 



Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1 from me

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

Re: Proposal to deprecate Maven 3.0.x

[Hervé BOUTEMY]

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  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: 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: Proposal to deprecate Maven 3.0.x

[Hervé BOUTEMY]

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  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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Proposal to deprecate Maven 3.0.x

[Karl Heinz Marbaise]

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  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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Proposal to deprecate Maven 3.0.x

[Elliotte Rusty Harold]

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  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: 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
>


-- 
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: Proposal to deprecate Maven 3.0.x

[Elliotte Rusty Harold]

On Thu, Apr 16, 2020 at 6:53 AM Tibor Digana  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.

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.

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.







-- 
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: Proposal to deprecate Maven 3.0.x

[Sylwester Lachiewicz]

So next quick question - should be 3.1.0 or 3.1.1 - last and recommend
version for Java 5?

Sylwester

czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana 
napisał:

> 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.
>
> On Thu, Apr 16, 2020 at 12:22 PM 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
> >
> > 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 
> 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: 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: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

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.

On Thu, Apr 16, 2020 at 12:22 PM 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
>
> 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  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: 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
>


-- 
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Hervé BOUTEMY]

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

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  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: 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: [CANCELLED] [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

I will open a new PR for issue 78.
Currently the issue is the $ end tag in pattern
https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgVersion.java#L50
however the number of versions should be limited to e.g. 3 which is
enough.

On Thu, Apr 16, 2020 at 8:22 AM Hervé BOUTEMY  wrote:
>
> this vote is cancelled because 2 issues found on Windows, with native gpg4win
> install or Git bash pgp port
> corresponding Jira issues created:
> https://issues.apache.org/jira/browse/MGPG-78
> https://issues.apache.org/jira/browse/MGPG-79
>
> please help fixing and testing
>
> Regards,
>
> Hervé
>
> Le dimanche 12 avril 2020, 14:50:08 CEST Hervé BOUTEMY a écrit :
> > Hi,
> >
> > We solved 13 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&ve
> > rsion=12330781&styleName=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1563/
> > https://repository.apache.org/content/repositories/maven-1563/org/apache/mav
> > en/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-gpg-plugin-3.0.0-source-release.zip sha512:
> > 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b542
> > 09a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> > -
> > 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
>


-- 
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Romain Manni-Bucau]

@Eric: no, it is the other way around, we must not abandon users of 5yo
versions IHO, we must pass it. it is not the case of 3.3 (it is exactly 5yo
and gap with 3.5 is 2 years, this is why i'd wait 1 more year to deprecate
3.3). That said in terms of impact for us, if you read the end of the
proposal it is the same for us: we ignore these versions for new plugin
versions. it is just not yet officially deprecated and we can have to do
maintenance releases on 3.3.

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



Le jeu. 16 avr. 2020 à 11:36, Eric Lilja  a écrit :

> 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  >
> wrote:
>
> > Hi Eric, point is that we can't deprecate 3.3 too IMHO.
> >
> > 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 jeu. 16 avr. 2020 à 11:18, Eric Lilja  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 <
> > rmannibu...@gmail.com
> > > >
> > > 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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le jeu. 16 avr. 2020 à 10:41, 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 <
> herve.bout...@free.fr
> > >
> > > > > 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 Artifac

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 
wrote:

> Hi Eric, point is that we can't deprecate 3.3 too IMHO.
>
> 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 jeu. 16 avr. 2020 à 11:18, Eric Lilja  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 <
> rmannibu...@gmail.com
> > >
> > 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  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le jeu. 16 avr. 2020 à 10:41, 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  >
> > > > 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.
> > > > > > 

Re: Proposal to deprecate Maven 3.0.x

[Romain Manni-Bucau]

Hi Eric, point is that we can't deprecate 3.3 too IMHO.

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



Le jeu. 16 avr. 2020 à 11:18, Eric Lilja  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  >
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 16 avr. 2020 à 10:41, 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 
> > > 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: dev-unsubscr...@maven.apache.org
> > > > > 

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 
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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 16 avr. 2020 à 10:41, 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 
> > 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: 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
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For addit

Re: Proposal to deprecate Maven 3.0.x

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 16 avr. 2020 à 10:41, 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 
> 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: 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
> >
>
>
> --
> Cheers
> Tibor
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

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  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: 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
>


-- 
Cheers
Tibor

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