Some of them are assigned to me. I won't make it before Wednesday but
like to address them in 3.5.1.
Michael
Am 2017-04-27 um 12:55 schrieb Robert Scholte:
Let me start going through the list of candidates:
Maven - Version 3.5.1-candidate
** Sub-task
* [MNG-6186] - switch to improved HawtJNI
Robert: Improvements have not been accepted yet, branch now has conflicts
** Bug
* [MNG-4347] - import-scoped dependencies of direct dependencies are
not resolved using profile modifications from settings.xml
Robert: Would like to postpone this. MRM must first be into place before
we can create proper integration tests (case seems to be too complex for
a unittest)
* [MNG-4463] - Dependency management import should support version
ranges.
Robert: I wasn't aware that ranges are allowed here, but so it seems. We
have a long list of depman issues, so maybe collect them for 3.6.x
* [MNG-5359] - Declared execution in PluginMgmt gets bound to
lifecycle (regression)
Robert: Seems to be a huge commit, but worth investigating. IIUC this is
only happening with plugins already bound the predefined lifecycles
* [MNG-5527] - Dependency management import should support relocations.
Robert: Seems valid
* [MNG-5935] - Optional true getting lost in managed dependencies
when transitive
Robert: should be fixed
* [MNG-5984] - Maven core extension resolution ignores repositories
from activeByDefault profiles in settings.xml
Robert: let's fix this, there's a patch, though not any test
* [MNG-6112] - Central repository in the 4.0.0 super POM should
declare update policy 'never'.
Robert: Don't think we should fix this.
* [MNG-6114] - Elements from the global settings should be ordered
before elements from the user settings.
Robert: In the end user settings should overwrite global settings. If
this is not happening, we should fix this.
* [MNG-6148] - Can't package and assemble with JDK9/Jigsaw
Robert: easy fix, let's do so.
* [MNG-6164] - Collections inconsistently immutable.
Robert: maintenance with a valid argument. Let's fix this
* [MNG-6188] - Console color not properly reset when interrupting
build process
Robert: I'm hitting this issue quite often (5-10% while interrupting a
jetty:run). There doesn't seem to be a way to reproduce this for
testing, because you are really killing the JVM. I think we should trust
the shutdownhook.
* [MNG-6216] - IndexArrayOutOfBounds when parsing POM
Robert: requires a fix in Plexus-utils, but want to solve this.
** Improvement
* [MNG-5457] - Show repository id when downloading or uploading
from/to a remote repository
Robert: Requires fix in Resolver, good for 3.5.1
* [MNG-5600] - Dependency management import should support exclusions.
Robert: Worth fixing
* [MNG-5639] - Support resolution of Import Scope POMs from Repo
that contains a ${parameter}
Robert: seems to be a complete patch: Let's fix this
* [MNG-6069] - Migrate to non deprecated parts of Commons CLI
Robert: Maintenance, let's fix this
* [MNG-6169] - Lifecycle/binding plugin version updates
Robert: Maintenance, let's fix this
* [MNG-6206] - We should produce a WARNING by using RELEASE, LATEST
as versions
Maybe a warning is too aggressive. There can be other plugins which are
capable to lock these versions before publishing, in which case it is
not an issue.
* [MNG-6207] - Create WARNINGs in case of using system scope
Maybe a warning is too aggressive. In some cases there's simply no other
solution, like referring to tools.jar.
** New Feature
* [MNG-6220] - Add CLI options to control color output
Robert: If we agree on the system property (just like changing the
colors), then yes.
** Task
* [MNG-2893] - Update the DefaultPluginManager to not use a project
depMan for controlling it's transitive dependencies
Robert: Description is minimal, but seems to make sense.
* [MNG-6167] - Clean up dependency mess (reported by
dependency:analyze)
Robert: Maintenance, let's fix this.
On Tue, 25 Apr 2017 22:43:54 +0200, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
I'd like people to take this next week to consider what issues we want to
pull in scope for 3.5.1.
If you are a committer, just add the issues to Fix Version of
3.5.1-candidate, ideally adding a comment at the same time with your
reasoning.
If once we have a seconding committer, they can just comment seconding
and
move the Fix Version to 3.5.1.
I'm going to suggest a 1 week period of open scoping. After that point in
time, my intent is to be more strict and apply "release manager risk
management" on any new issues being targeted for 3.5.1. Similarly, if
issues targeted for 3.5.1 are not making sufficient progress they will be
dropped... but for now... it's open season!
Get triaging!
-Stephen
---------------------------------------------------------------------
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
