[jira] [Commented] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[Henning Schmiedehausen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893527#comment-15893527
 ] 

Henning Schmiedehausen commented on MRELEASE-979:
-

(good bot, ASF Github Bot)

A few words to the changes: 

This reintroduces the branchoperation boolean to the Naming request again and I 
know that [~rfscholte] cringed at that. Let me explain: As you want the default 
naming policy to live within the DefaultNamingPolicy class, here is a dirty 
secret: We actually have two naming policies: 

- one for tags, where the name is created from "artifactid - version" (unless 
an ScmTagName is given) 
- one for branches, where the name is unconditionally empty unless explicitly 
given

I updated the NamingPolicy class (and default implementation) to support two 
methods instead of one, one for tag names, one for branches.


The logic in the InputVariablesPhase is a bit delicate and reordering it tends 
to break in subtle ways. I tested this back and forth with a ll the projects 
that we have and I think that this patch works in every scenario. 


> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893515#comment-15893515
 ] 

ASF GitHub Bot commented on MRELEASE-979:
-

GitHub user hgschmie opened a pull request:

https://github.com/apache/maven-release/pull/14

MRELEASE-979 fixes 

The proposed (and merged) change has the following problems (IAW it does 
not work at all):

- The selected naming policy is not copied in all places; especially it is 
not copied when merging with the properties loaded from the release.properties 
file. As a result, it always reverts to 'default'
- The current logic only executes the naming policy if the scmTagName is 
unset. This is counter-intuitive (to say the least). My original proposed patch 
did not have that problem. Change this to execute unconditionally if the 
operation requested is a branch operation, otherwise only if the scmTagName is 
unset
- The current logic failed unconditionally if the build is non-interactive 
and a branch operation is requested. 

This pull request fixes all of the mentioned problems. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgschmie/maven-release MRELEASE-979-fixes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-release/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit 5b17a0e21d59170a905d2d8eea4d0cb7f3d3bb65
Author: Henning Schmiedehausen 
Date:   2017-03-03T00:19:07Z

Adds missing places where the naming policy id is not copied.

commit d505400d3cdc69d930e98c8287973e79e8be9756
Author: Henning Schmiedehausen 
Date:   2017-03-03T00:20:04Z

Fixes the naming policy logic.

- Ensure that the naming policy is executed when a branch is requested even 
if an scm tag name is set.
- Ensure that in non-interactive mode, the plugin does not fail 
unconditionally if a branch is requested.




> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[Henning Schmiedehausen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893386#comment-15893386
 ] 

Henning Schmiedehausen commented on MRELEASE-979:
-

Finally got around to review those changes and update our internal policy code 
to try to use this change.

The bad news: It is all broken for me. In fact, the code does not work at all.

- there are at least two places where the naming policy value is not copied 
over. The name always reverts to "default" by the time it hits the 
InputVariablesPhase.
- the naming policy is only called when scmTagName is not set, even for a 
branch name. This is counter-intuitive because I would not expect scmTagName to 
influence the release:branch operation.

and finally, the naming policy do not work with release:branch at all in 
non-interactive mode (which makes it pretty worthless to me):

- the policy is only executed when no scmTagName is set into defaultTag but 
then this value is never used again when in branchOperation mode. The execution 
always hits the "no branch name" given exception.

I will send a patch that addresses these problems. 

> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEP-555) outputDirectory is not used

[Thomas Hartwig (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893170#comment-15893170
 ] 

Thomas Hartwig commented on MDEP-555:
-

It turned out the outputDirectory was configured in the wrong section, instead 
within the execution settings it must be configured as the plugin configuration 
see below. So my report is not valid. Probably it is worth to include a 
complete example in the usage guide: 
https://maven.apache.org/plugins/maven-dependency-plugin/usage.html

{code:xml}

org.apache.maven.plugins
maven-dependency-plugin
3.0.0

${project.lib.dir}



copy-dependencies
package

copy-dependencies


false
false
true




{code}

> outputDirectory is not used
> ---
>
> Key: MDEP-555
> URL: https://issues.apache.org/jira/browse/MDEP-555
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy-dependencies
>Affects Versions: 2.8, 3.0.0
> Environment: Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-64-generic", arch: "amd64", family: "unix"
>Reporter: Thomas Hartwig
>
> I use the configuration below to be able to copy all dependencies. The 
> problem is the outputDirectory is not used. The files are copied to 
> target/dependency of the project dir instead. Tested in 3.0.0 and 2.8.
> {code:xml}
> 
> /tmp/
> 
> 
> false
> false
> true
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (MDEP-555) outputDirectory is not used

[Thomas Hartwig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Hartwig closed MDEP-555.
---
Resolution: Invalid

> outputDirectory is not used
> ---
>
> Key: MDEP-555
> URL: https://issues.apache.org/jira/browse/MDEP-555
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy-dependencies
>Affects Versions: 2.8, 3.0.0
> Environment: Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-64-generic", arch: "amd64", family: "unix"
>Reporter: Thomas Hartwig
>
> I use the configuration below to be able to copy all dependencies. The 
> problem is the outputDirectory is not used. The files are copied to 
> target/dependency of the project dir instead. Tested in 3.0.0 and 2.8.
> {code:xml}
> 
> /tmp/
> 
> 
> false
> false
> true
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MEAR-217) Snapshot dependencies are not deleted from skinny WARs

[JIRA]

[ 
https://issues.apache.org/jira/browse/MEAR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893113#comment-15893113
 ] 

Guillaume Boué commented on MEAR-217:
-

Yes, the fix is available in the latest 3.0.0-SNAPSHOT deployed on Apache 
snapshot repo. Are you using {{true}}? There 
was an IT added to verify the behaviour, can you check against that?

> Snapshot dependencies are not deleted from skinny WARs
> --
>
> Key: MEAR-217
> URL: https://issues.apache.org/jira/browse/MEAR-217
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Reporter: Tamás Baráth
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
> Attachments: jar-sample-one-1.0-20150825.210557-91.jar, 
> maven-ear-plugin.patch, test-project.zip
>
>
> EAR plugin doesn't delete snapshot dependencies from skinny WARs if Maven has 
> downloaded that dependencies from a remote repository. The EAR contains the 
> files in library bundle directory and in WEB-INF/lib folder of the WARs as 
> well.
> When snapshots are installed to local repository with 'mvn install' command, 
> the plugin works fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MEAR-217) Snapshot dependencies are not deleted from skinny WARs

[Jon Gunnip (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEAR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893048#comment-15893048
 ] 

Jon Gunnip commented on MEAR-217:
-

I'm using 3.0.0-SNAPSHOT from http://repository.apache.org/snapshots/ and I'm 
still see the original behavior of the bug.  Should the fix be available now at 
http://repository.apache.org/snapshots/?

> Snapshot dependencies are not deleted from skinny WARs
> --
>
> Key: MEAR-217
> URL: https://issues.apache.org/jira/browse/MEAR-217
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Reporter: Tamás Baráth
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
> Attachments: jar-sample-one-1.0-20150825.210557-91.jar, 
> maven-ear-plugin.patch, test-project.zip
>
>
> EAR plugin doesn't delete snapshot dependencies from skinny WARs if Maven has 
> downloaded that dependencies from a remote repository. The EAR contains the 
> files in library bundle directory and in WEB-INF/lib folder of the WARs as 
> well.
> When snapshots are installed to local repository with 'mvn install' command, 
> the plugin works fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEP-555) outputDirectory is not used

[JIRA]

[ 
https://issues.apache.org/jira/browse/MDEP-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892784#comment-15892784
 ] 

Guillaume Boué commented on MDEP-555:
-

I cannot reproduce this behaviour, and it is [tested with an 
IT|https://github.com/apache/maven-plugins/tree/trunk/maven-dependency-plugin/src/it/projects/copy-dependencies].
 Would you happen to have this configuration in a execution block, and trying 
to execute it on the command-line? Can you give a complete example?

> outputDirectory is not used
> ---
>
> Key: MDEP-555
> URL: https://issues.apache.org/jira/browse/MDEP-555
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy-dependencies
>Affects Versions: 2.8, 3.0.0
> Environment: Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-64-generic", arch: "amd64", family: "unix"
>Reporter: Thomas Hartwig
>
> I use the configuration below to be able to copy all dependencies. The 
> problem is the outputDirectory is not used. The files are copied to 
> target/dependency of the project dir instead. Tested in 3.0.0 and 2.8.
> {code:xml}
> 
> /tmp/
> 
> 
> false
> false
> true
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

[Brian D. Johnson (JIRA)]

Brian D. Johnson created MRESOURCES-237:
---

 Summary: Resource plugin's handling of symbolic links changed in 
3.0.x, broke existing behavior
 Key: MRESOURCES-237
 URL: https://issues.apache.org/jira/browse/MRESOURCES-237
 Project: Maven Resources Plugin
  Issue Type: Bug
Affects Versions: 3.0.2, 3.0.1, 3.0.0
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
"unix"
Reporter: Brian D. Johnson
Priority: Minor


It looks like the handling of symbolic links in the {{maven-resources-plugin}} 
has changed in version 3.0.x.  I'm submitting a JIRA because it breaks the 
previous behavior and I have not been able to find this documented anywhere as 
an intended change.

*Use case:* Multi-module maven project.  We have a custom log4j2 configuration 
file we use during testing.  Instead of maintaining this file in multiple 
{{src/test/resources}} directories, we instead maintain a single copy of the 
file at the project's root level and create symbolic links from each module's 
{{src/test/resources}} directory to the file using relative paths.

*2.7 Behavior:* the symlink was evaluated and the target file was copied to 
{{target/test-classes/}}.

*3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.  
The symlink's relative path results in the symlink pointing to the wrong file 
location.  The log4j2 configuration is not found.

*Requested Change:* Either revert to the original 2.7 behavior, or document the 
change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MDEP-556) The dependency:resolve goal tries to resolve all dependencies, regardless of the exclude filters

[JIRA]

Yoann Rodière created MDEP-556:
--

 Summary: The dependency:resolve goal tries to resolve all 
dependencies, regardless of the exclude filters
 Key: MDEP-556
 URL: https://issues.apache.org/jira/browse/MDEP-556
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: resolve
Affects Versions: 3.0.0
Reporter: Yoann Rodière


My use case was to download dependencies in a CI script, before executing the 
build. To that end, I wanted to execute something along the lines of:

{noformat}
mvn -q -B dependency:resolve 
-DexcludeArtifactIds='hibernate-search-integrationtest-wildfly'
{noformat}

... {{hibernate-search-integrationtest-wildfly}} being a module that other 
modules in my project depend on.

But I get this stacktrace:

{noformat}
[ERROR] Failed to execute goal on project hibernate-search-performance: Could 
not resolve dependencies for project 
org.hibernate:hibernate-search-performance:jar:5.8.0-SNAPSHOT: Cannot access 
jboss-public-repository-group 
(https://repository.jboss.org/nexus/content/groups/public-jboss/) in offline 
mode and the artifact 
org.hibernate:hibernate-search-integrationtest-wildfly:jar:tests:5.8.0-SNAPSHOT 
has not been downloaded from it before. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
on project hibernate-search-performance: Could not resolve dependencies for 
project org.hibernate:hibernate-search-performance:jar:5.8.0-SNAPSHOT: Cannot 
access jboss-public-repository-group 
(https://repository.jboss.org/nexus/content/groups/public-jboss/) in offline 
mode and the artifact 
org.hibernate:hibernate-search-integrationtest-wildfly:jar:tests:5.8.0-SNAPSHOT 
has not been downloaded from it before.
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:221)
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:245)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
resolve dependencies for project 
org.hibernate:hibernate-search-performance:jar:5.8.0-SNAPSHOT: Cannot access 
jboss-public-repository-group 
(https://repository.jboss.org/nexus/content/groups/public-jboss/) in offline 
mode and the artifact 
org.hibernate:hibernate-search-integrationtest-wildfly:jar:tests:5.8.0-SNAPSHOT 
has not been downloaded from it before.
at 
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:211)
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
... 23 more
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Cannot 
access jboss-public-repository-group 
(https://repository.jboss.org/nexus/content/groups/public-jboss/) in offline 
mode and the artifact 

[jira] [Commented] (MNG-5585) match server credentials based on server realm

[Andreas Sewe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892585#comment-15892585
 ] 

Andreas Sewe commented on MNG-5585:
---

FYI, Eclipse Tycho has recently (version 1.0.0) introduced a similar feature 
for [sharing mirror settings for multiple 
repositories|https://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors#Mirroring_multiple_Repositories].
 As this feature request is similar (sharing settings/credentials for multiple 
repositories), the configuration syntax chosen by the Tycho developers 
(overloading repository/id) may serve as inspiration.

> match server credentials based on server realm
> --
>
> Key: MNG-5585
> URL: https://issues.apache.org/jira/browse/MNG-5585
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.x / Backlog
>Reporter: nicolas de loof
>
> credentials for repositories are identified based on arbitrary ID. This is 
> error prone and fragile design, especially as there's no way to diagnose 
> which credentials are used (see MNG-5584).
> A realm-based server matching would better follow the way HTTP security is 
> defined, and could be easily used for other protocols based (for sample) on 
> domain name.
> 
>  xxx  
>  [optional protocol://]repo.acme.com
> ..
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MDEP-555) outputDirectory is not used

[Thomas Hartwig (JIRA)]

Thomas Hartwig created MDEP-555:
---

 Summary: outputDirectory is not used
 Key: MDEP-555
 URL: https://issues.apache.org/jira/browse/MDEP-555
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 3.0.0, 2.8
 Environment: Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-64-generic", arch: "amd64", family: "unix"

Reporter: Thomas Hartwig


I use the configuration below to be able to copy all dependencies. The problem 
is the outputDirectory is not used. The files are copied to target/dependency 
of the project dir instead. Tested in 3.0.0 and 2.8.
{code:xml}

/tmp/


false
false
true

{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MNG-6173) MavenSession.getAllProjects() should return all projects in the reactor

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892084#comment-15892084
 ] 

Christian Schulte commented on MNG-6173:


Would be cool if you could open a pull request against the 
maven-integration-testing repository providing integration tests for the issue.


> MavenSession.getAllProjects() should return all projects in the reactor
> ---
>
> Key: MNG-6173
> URL: https://issues.apache.org/jira/browse/MNG-6173
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Christoph Böhme
>
> According to MNG-5582 {{MavenSession.getAllProjects()}} should return all 
> projects in the reactor even if the set is constrained by {{--projects}}. The 
> current implementation, however, returns the same constrained list that is 
> returned by {{MavenSession.getProjects()}}.
> This bug seems to have been introduced when MNG-5775 was implemented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)