Release 3.6.0 - cleaning up JIRA

[Enrico Olivelli]

HI,
I have moved to fixversion=3.7.0 all of the issues with fixversion = 3.6.0
and resolution = empty.

Please add the '3.6.0' label to the issues that should go into 3.6.0.

Candidates are:
- blocker issues (regressions)
- build environment issues
- flaky tests
- patches that are really ready for commit, just last round of
review/comment resolution (we have a few)
- missing documentation for new important features
- license files related issues (we are now adding OpenSSL for instance)
- upgrade of dependencies flagged by OWASP or any other public directory
.

As soon as I create the branch-3.6 please ping me on every patch you want
to cherry pick


Best regards
Enrico

MENFORCER-288 - maybe reject?

[Benjamin Marwell]

Hi all,

I just tried to implement MENFORCER-288 to see how far I could get.
As it turned out, the task is not trivial, because you'd have to parse and
correctly rewrite a version range. See details in the comments on
MENFORCER-288.
Because of this, I don't think the recommendation to use JavaVersion would
help here (at the moment).

I'd vote to close it, because it might not be worth implementing, as it is
a lot of effort for few gains.

However, it would be much easier to achieve if
* JavaVersion would get a normalize method (ie converts 6 to 1.6)
* VersionRange was iterate and modifiable (so that [6] could be converted
to [1.6].

As I am new here, I'd love to hear how to proceed and how a decision on
this would be made.

Have a good weekend,
Ben

MCHECKSTYLE-373

[Benjamin Marwell]

Hi all,

I think issue  this can be closed:
   https://issues.apache.org/jira/browse/MCHECKSTYLE-373
The original author is just asking for how to specify a property via
command line.

Best regards,
Ben

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

JDK 14 enters Rampdown Phase One

[Rory O'Donnell]

Hi Robert ,

*Per the JDK 14 schedule , we are now in Rampdown Phase One*

*Please advise if you have found any issues while testing the latest 
Early Access build.

*

 * Schedule for JDK 14
 o *2019/12/12 Rampdown Phase One*
 o 2020/01/16 Rampdown Phase Two
 o 2020/02/06 Initial Release Candidate
 o 2020/02/20 Final Release Candidate
 o 2020/03/17 General Availability

 * The overall feature set is frozen.
 o No further JEPs will be targeted to this release
 o For more details , see Mark Reinhold's email to jdk-dev mailing
   list [1]

 * Features included in JDK 14:.
 o JEP 305: Pattern Matching for instanceof (Preview)
   
 o JEP 343: Packaging Tool (Incubator)
   
 o JEP 345: NUMA-Aware Memory Allocation for G1
   
 o JEP 349: JFR Event Streaming 
 o JEP 352: Non-Volatile Mapped Byte Buffers
   
 o JEP 358: Helpful NullPointerExceptions
   
 o JEP 359: Records (Preview) 
   JEP 359: Records (Preview) 
 o JEP 361: Switch Expressions (Standard)
   
 o JEP 362: Deprecate the Solaris and SPARC Ports
   
 o JEP 363: Remove the Concurrent Mark Sweep Garbage Collector
   
 o JEP 364: ZGC on macOS 
 o JEP 365 ZGC on Windows 
 o JEP 366: Deprecate ParallelScavenge  SerialOld GC Combination
   
 o JEP 367: Remove the Pack200 Tools and API
   
 o JEP 368: Text Blocks (Second Preview)
   
 o JEP 370: Foreign-Memory Access API (Incubator)
   

*JDK 14 **Early Access build 27 **is available**at : - jdk.java.net/14/*

 * Release notes
 o https://jdk.java.net/14/release-notes
 * Recent fixes that might be of interest
 o Build 27:
 + JDK-8212780: Packaging Tool Implementation
 + JDK-8234370: Implementation of JEP 362: Deprecate the
   Solaris and SPARC Ports
 + JDK-8190492: Remove SSLv2Hello and SSLv3 from default
   enabled TLS protocols
 + JDK-8214481: freetype path does not disable TrueType hinting
   with AA+FM hints
 + JDK-8234076: JVM crashes on Windows 10 using --module=NAME
 + JDK-8222756: Plural support in CompactNumberFormat
 + JDK-8234211: allow discoverable javac plugins to be invoked
   by default
 o Build 26:
 + JDK-8233223: Add Amazon Root CA certificates
 + JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
 + JDK-8234893: ARM32: build failure after JDK-8234387

Rgds, Rory

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003795.html



--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: New Commiter: Elliotte Rusty Harold

[Robert Scholte]

Welcome and enjoy!

Robert

On 13-12-2019 17:29:37, Karl Heinz Marbaise  wrote:
Hi Elliotte,

the Project Management Committee (PMC) for Apache Maven
has invited you Elliotte to become a committer and
we are pleased to announce that you have accepted the invitation.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.

Elliotte, welcome and enjoy!

Kind regards
Karl Heinz Marbaise

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

Re: Defining EoL for Older Maven Versions

[Karl Heinz Marbaise]

Hi,

On 14.12.19 13:14, Michael Osipov wrote:

If so, we have to define what "Support" and "Test" mean and post that on
the website. I think this is an issue!


Very good point.

Kind regards
Karl Heinz Marbaise


M

Am 2019-12-14 um 13:07 schrieb Karl Heinz Marbaise:

Hi,

I have a different opionion about End Of Life ...

at moment we are only testing our plugins with Maven 3.2.5 as lowest
version... we had the same dicussion more than a year before[1].

I see it simply as that:

We don't test all our plugins against versions like:

3.0.5, 3.1.1

This implies those plugins versions are not active being tested via our
CI...

The lowest version which we are currently testing is 3.2.5 see [2] and
[3]

Apart from that:

The implication saying we define EoL for version X does not mean we will
backport some issues to other versionsmaybe we decide to do that
based on Security issue etc. (the only reason I can imagine to do that)..

Furthermore the part you have suggest to support 3.6.X line with patches
for a time has never been done for earlier versions as well. We alway
work on most recent version..as you already mention we recommend in all
tickets to upgrade first...that strategy should being kept..


 From my point of view we should lift a new baseline to Maven 3.3.9 as
lowest version...any other version should be define as End Of Life...



Kind regards
Karl Heinz Marbaise

[1]
https://lists.apache.org/thread.html/9e0d47814e84b75ac87bc88c84c1c029fe4b63beed46c82dab1121b9%40%3Cdev.maven.apache.org%3E

[2]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/master/

[3]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-compiler-plugin/job/master/


On 14.12.19 12:43, Michael Osipov wrote:

Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?


That sounds like a plan, but not honest enough. If we include 3.3.9 and
3.5.4 we ultimately say that we still support this and patch it. But we
don't! In tickets we require always to try to the latest version.

What I would see as honest is that we would support 3.6.x with bugfixes
for some amount of time and have a line moving forward, 3.7.x.
Everything else is just a lie.

Michael



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

Re: Defining EoL for Older Maven Versions

[Michael Osipov]

If so, we have to define what "Support" and "Test" mean and post that on 
the website. I think this is an issue!


M

Am 2019-12-14 um 13:07 schrieb Karl Heinz Marbaise:

Hi,

I have a different opionion about End Of Life ...

at moment we are only testing our plugins with Maven 3.2.5 as lowest
version... we had the same dicussion more than a year before[1].

I see it simply as that:

We don't test all our plugins against versions like:

3.0.5, 3.1.1

This implies those plugins versions are not active being tested via our
CI...

The lowest version which we are currently testing is 3.2.5 see [2] and [3]

Apart from that:

The implication saying we define EoL for version X does not mean we will
backport some issues to other versionsmaybe we decide to do that
based on Security issue etc. (the only reason I can imagine to do that)..

Furthermore the part you have suggest to support 3.6.X line with patches
for a time has never been done for earlier versions as well. We alway
work on most recent version..as you already mention we recommend in all
tickets to upgrade first...that strategy should being kept..


 From my point of view we should lift a new baseline to Maven 3.3.9 as
lowest version...any other version should be define as End Of Life...



Kind regards
Karl Heinz Marbaise

[1]
https://lists.apache.org/thread.html/9e0d47814e84b75ac87bc88c84c1c029fe4b63beed46c82dab1121b9%40%3Cdev.maven.apache.org%3E 


[2]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/master/ 


[3]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-compiler-plugin/job/master/ 



On 14.12.19 12:43, Michael Osipov wrote:

Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?


That sounds like a plan, but not honest enough. If we include 3.3.9 and
3.5.4 we ultimately say that we still support this and patch it. But we
don't! In tickets we require always to try to the latest version.

What I would see as honest is that we would support 3.6.x with bugfixes
for some amount of time and have a line moving forward, 3.7.x.
Everything else is just a lie.

Michael







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

Re: Defining EoL for Older Maven Versions

[Karl Heinz Marbaise]

Hi,

On 14.12.19 12:59, Benjamin Marwell wrote:

I do know companies who still use 3.2.3 and they don't dare to update
because of a misconfiguration.


If we start to use this argument we need to go back and support Maven 2
as well cause it's used somewhere in the wild ...



Should we care? Or perhaps they should have bought support contracts
for such use cases?


If people don't upgrade/maintain their build for more than five++ years
I think there is a big issue...

And yes maybe the should find some consultant to fix their issues...

Kind regards
Karl Heinz Marbaise





If we say "support the 3.6 branch fur such amount of time" it also
means reacting to vulnerabilities in time, doesn't it?

But yes, better have a clear statement than no statement at all.

Am Sa., 14. Dez. 2019 um 12:43 Uhr schrieb Michael Osipov :


Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?


That sounds like a plan, but not honest enough. If we include 3.3.9 and
3.5.4 we ultimately say that we still support this and patch it. But we
don't! In tickets we require always to try to the latest version.

What I would see as honest is that we would support 3.6.x with bugfixes
for some amount of time and have a line moving forward, 3.7.x.
Everything else is just a lie.

Michael


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

Re: Defining EoL for Older Maven Versions

[Karl Heinz Marbaise]

Hi,

I have a different opionion about End Of Life ...

at moment we are only testing our plugins with Maven 3.2.5 as lowest
version... we had the same dicussion more than a year before[1].

I see it simply as that:

We don't test all our plugins against versions like:

3.0.5, 3.1.1

This implies those plugins versions are not active being tested via our
CI...

The lowest version which we are currently testing is 3.2.5 see [2] and [3]

Apart from that:

The implication saying we define EoL for version X does not mean we will
backport some issues to other versionsmaybe we decide to do that
based on Security issue etc. (the only reason I can imagine to do that)..

Furthermore the part you have suggest to support 3.6.X line with patches
for a time has never been done for earlier versions as well. We alway
work on most recent version..as you already mention we recommend in all
tickets to upgrade first...that strategy should being kept..


From my point of view we should lift a new baseline to Maven 3.3.9 as
lowest version...any other version should be define as End Of Life...



Kind regards
Karl Heinz Marbaise

[1]
https://lists.apache.org/thread.html/9e0d47814e84b75ac87bc88c84c1c029fe4b63beed46c82dab1121b9%40%3Cdev.maven.apache.org%3E
[2]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/master/
[3]
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-compiler-plugin/job/master/

On 14.12.19 12:43, Michael Osipov wrote:

Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?


That sounds like a plan, but not honest enough. If we include 3.3.9 and
3.5.4 we ultimately say that we still support this and patch it. But we
don't! In tickets we require always to try to the latest version.

What I would see as honest is that we would support 3.6.x with bugfixes
for some amount of time and have a line moving forward, 3.7.x.
Everything else is just a lie.

Michael




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

Re: Defining EoL for Older Maven Versions

[Benjamin Marwell]

I do know companies who still use 3.2.3 and they don't dare to update
because of a misconfiguration.
Should we care? Or perhaps they should have bought support contracts
for such use cases?

If we say "support the 3.6 branch fur such amount of time" it also
means reacting to vulnerabilities in time, doesn't it?

But yes, better have a clear statement than no statement at all.

Am Sa., 14. Dez. 2019 um 12:43 Uhr schrieb Michael Osipov :
>
> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > based on the history we have defined Maven 2.X EoL five years after the
> > last release...[1]
> >
> > Based on that I would suggest to define End Of Life for the following
> > Maven versions cause their release date is also five years ago...
> >
> >
> > Maven 3.0.5...3.2.5 included.
> >
> > We have never backported some things in the last five year...
> >
> > WDYT?
>
> That sounds like a plan, but not honest enough. If we include 3.3.9 and
> 3.5.4 we ultimately say that we still support this and patch it. But we
> don't! In tickets we require always to try to the latest version.
>
> What I would see as honest is that we would support 3.6.x with bugfixes
> for some amount of time and have a line moving forward, 3.7.x.
> Everything else is just a lie.
>
> Michael
>
> -
> 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: Defining EoL for Older Maven Versions

[Aleksandar Kurtakov]

On Sat, Dec 14, 2019 at 1:50 PM Michael Osipov  wrote:

> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > based on the history we have defined Maven 2.X EoL five years after the
> > last release...[1]
> >
> > Based on that I would suggest to define End Of Life for the following
> > Maven versions cause their release date is also five years ago...
> >
> >
> > Maven 3.0.5...3.2.5 included.
> >
> > We have never backported some things in the last five year...
> >
> > WDYT?
>
> That sounds like a plan, but not honest enough. If we include 3.3.9 and
> 3.5.4 we ultimately say that we still support this and patch it. But we
> don't! In tickets we require always to try to the latest version.
>
> What I would see as honest is that we would support 3.6.x with bugfixes
> for some amount of time and have a line moving forward, 3.7.x.
> Everything else is just a lie.
>

+1. Setting clear expectations is better than letting people live with
their (false) hopes.


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

-- 
Alexander Kurtakov
Red Hat Eclipse Team

Re: Please close MCHECKSTYLE-378

[Benjamin Marwell]

You're welcome. I am cleaning up some of them and trying to reproduce
some issues which might not be an issue anymore.
Also, I have 3 Pending PRs where some of the maven checkstyle
maintainers kindly looked into them:
https://github.com/apache/maven-checkstyle-plugin/pulls/bmhm

I also just send my ICLA. If there's anything else I should know,
please let me know.

Best regards,
Ben

Am Sa., 14. Dez. 2019 um 12:33 Uhr schrieb Karl Heinz Marbaise
:
>
> Hi Benjamin,
>
> thanks helping to clean up the issue base.
>
> I've done so.
>
> Kind regards
> Karl Heinz Marbaise
> On 14.12.19 12:29, Benjamin Marwell wrote:
> > Dear devs,
> >
> > I am positive that
> > https://issues.apache.org/jira/browse/MCHECKSTYLE-378 can be closed.
> > The user tried to use a configuration for the wrong goal, see comment.
> >
> > Proposed resolution: Not a bug.
> >
> > Thanks,
> > Ben

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

Re: Defining EoL for Older Maven Versions

[Michael Osipov]

Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?


That sounds like a plan, but not honest enough. If we include 3.3.9 and 
3.5.4 we ultimately say that we still support this and patch it. But we 
don't! In tickets we require always to try to the latest version.


What I would see as honest is that we would support 3.6.x with bugfixes 
for some amount of time and have a line moving forward, 3.7.x. 
Everything else is just a lie.


Michael

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

Re: Please close MCHECKSTYLE-378

[Karl Heinz Marbaise]

Hi Benjamin,

thanks helping to clean up the issue base.

I've done so.

Kind regards
Karl Heinz Marbaise
On 14.12.19 12:29, Benjamin Marwell wrote:

Dear devs,

I am positive that
https://issues.apache.org/jira/browse/MCHECKSTYLE-378 can be closed.
The user tried to use a configuration for the wrong goal, see comment.

Proposed resolution: Not a bug.

Thanks,
Ben


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

Defining EoL for Older Maven Versions

[Karl Heinz Marbaise]

Hi,

based on the history we have defined Maven 2.X EoL five years after the
last release...[1]

Based on that I would suggest to define End Of Life for the following
Maven versions cause their release date is also five years ago...


Maven 3.0.5...3.2.5 included.

We have never backported some things in the last five year...

WDYT?

Kind regards
Karl Heinz Marbaise


[1]: https://maven.apache.org/docs/history.html#Maven_2

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

Please close MCHECKSTYLE-378

[Benjamin Marwell]

Dear devs,

I am positive that
https://issues.apache.org/jira/browse/MCHECKSTYLE-378 can be closed.
The user tried to use a configuration for the wrong goal, see comment.

Proposed resolution: Not a bug.

Thanks,
Ben

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

Re: Integration Tests of Maven Core

[Karl Heinz Marbaise]

Hi,

there have been different opinions about removing tests.

let me summarize that a little bit:

1. For People who want to make patches to old releases
   just clone/fork the repository and keep that state. Also
   valid for people who having customers which need patches/fixes
   from time to time on old versions. (I'm doing that for a few
   of my customers as well. I have private copies of the software).

2. Historical record is of course a valid reason

   But we could simply do a branch related 1:1 to Maven Core Version
   as already suggested.

   That would make it easier to create tag on the integration tests
   as well which currently do not exist (which I find a
   problematic).

3. Dropping everything which has no value anymore

   This means removing any tests which are Maven 2 releated
   (Of course doing something as mentioned before) as first step.

   This will drop the amount of code which needs to be maintained.

4. Keeping it in a separate repository

   From my point of view it's a good idea cause it makes
   it more a conscious decision and not accidently by using
   an IDE by refactoring etc. or something similar to change
   the integration tests.

   But of course I think we should make it easier to
   run IT's on a change you/someone have made (scripting / Docker etc.
   whatever)...

Kind regards
Karl Heinz Marbaise

On 08.12.19 20:10, Karl Heinz Marbaise wrote:

Hi,
I'm diving a little bit into the integration tests of maven core...

and I realized that at the moment this list of IT's is SKIPPED
based on the version of Maven Core:

mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
mng5889FindBasedir(MvnFileShortOptionModule)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
mng5889FindBasedir(MvnFileShortOption)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
mng5889FindBasedir(MvnFileLongOption)...SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)...SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (3.3.3,3.5.0-alpha)
mng4428FollowHttpRedirect(itHttpToHttps)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0]
mng4428FollowHttpRedirect(itHttpsToHttp)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0]
mng4279WagonProviderFailover(it)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.2.1,3.0-alpha-1)
mng4254SelectableWagonProviders(DefaultHttpsWagon)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
mng4254SelectableWagonProviders(DefaultHttpWagon)...SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
mng4254SelectableWagonProviders(SettingsUsage)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
mng4254SelectableWagonProviders(CliUsage)...SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
mng4126ParentProfilesXml(itReactorBuild)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,2.1.0),(2.1.0,3.0-alpha-1)
mng4126ParentProfilesXml(itChildOnlyBuild)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,2.1.0),(2.1.0,3.0-alpha-1)
mng4086ExplicitPluginMetaversion(itRelease).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0.6,3.0-alpha-3)
mng4086ExplicitPluginMetaversion(itLatest)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0.6,3.0-alpha-3)
mng4036ParentResolutionFromSettingsRepo(itLegacyLayout).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-3)
mng3991ValidDependencyScope(it).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [4.0,)
mng3983PluginResolutionFromProfileRepos(itFromProfilesXml)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
mng3970DepResolutionFromProfileRepos(itFromProfilesXml).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
mng3948ParentResolutionFromProfileRepos(itFromProfilesXml)..SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
mng3933ProfilesXmlActivation(itMNG3933).SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
mng3885UniqueVersionFromParentProfile(itUniqueVersionReactor)SKIPPED -
Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
mng3885UniqueVersionFromParentProfile(itUniqueVersionStandalone)SKIPPED
- Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
mng3885UniqueVersionFromParentProfile(itNonUniqueVersionStandalone)SKIPPED
- Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
mng3885UniqueVersionFromParentProfile(itNonUniqueVersionReactor)SKIPPED
- Maven version 3.7.0-SNAPSHOT not in range 

Re: Yearly JIRA cleanup

[Michael Osipov]

Am 2019-12-13 um 16:08 schrieb Elliotte Rusty Harold:

NVM, I seem to have access now. I think I just needed to logout with
my old credentials and back in with the new ones.


Elliotte,

please go through the list and update those tickets you seen to be 
addressible within a decent timeframe.


Michael

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