[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942053#comment-15942053 ] Christian Schulte commented on MNG-6112: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-6112: Assignee: (was: Christian Schulte) > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-11: Assignee: (was: Christian Schulte) > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-13) Exceptions are suppressed incorrectly when closing resources fails.
[ https://issues.apache.org/jira/browse/MRESOLVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-13: Assignee: (was: Christian Schulte) > Exceptions are suppressed incorrectly when closing resources fails. > --- > > Key: MRESOLVER-13 > URL: https://issues.apache.org/jira/browse/MRESOLVER-13 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942045#comment-15942045 ] Christian Schulte commented on MRESOLVER-11: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-12) Addition of unit tests for the various DependencySelector implementations to test things are working as documented.
[
https://issues.apache.org/jira/browse/MRESOLVER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942046#comment-15942046
]
Christian Schulte commented on MRESOLVER-12:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When
interested, you can cherry pick the commit to your own repository and create a
pull request for the apache master branch with just this commit yourself from
there.
> Addition of unit tests for the various DependencySelector implementations to
> test things are working as documented.
> ---
>
> Key: MRESOLVER-12
> URL: https://issues.apache.org/jira/browse/MRESOLVER-12
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{DefaultDependencyCollector}} heavily relies on various components
> provided by an application. There should be unit tests for testing that at
> least the {{ScopeDependencySelector}} and {{OptionalDependencySelector}}
> selector are working as stated in the Javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-12) Addition of unit tests for the various DependencySelector implementations to test things are working as documented.
[
https://issues.apache.org/jira/browse/MRESOLVER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MRESOLVER-12:
Assignee: (was: Christian Schulte)
> Addition of unit tests for the various DependencySelector implementations to
> test things are working as documented.
> ---
>
> Key: MRESOLVER-12
> URL: https://issues.apache.org/jira/browse/MRESOLVER-12
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{DefaultDependencyCollector}} heavily relies on various components
> provided by an application. There should be unit tests for testing that at
> least the {{ScopeDependencySelector}} and {{OptionalDependencySelector}}
> selector are working as stated in the Javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-13) Exceptions are suppressed incorrectly when closing resources fails.
[ https://issues.apache.org/jira/browse/MRESOLVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MRESOLVER-13: --- Comment: was deleted (was: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there.) > Exceptions are suppressed incorrectly when closing resources fails. > --- > > Key: MRESOLVER-13 > URL: https://issues.apache.org/jira/browse/MRESOLVER-13 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MRESOLVER-13) Exceptions are suppressed incorrectly when closing resources fails.
[ https://issues.apache.org/jira/browse/MRESOLVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MRESOLVER-13. -- Resolution: Fixed > Exceptions are suppressed incorrectly when closing resources fails. > --- > > Key: MRESOLVER-13 > URL: https://issues.apache.org/jira/browse/MRESOLVER-13 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-14) Statistics should be calculated using System.nanoTime instead of System.currentTimeMillis.
[ https://issues.apache.org/jira/browse/MRESOLVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MRESOLVER-14: --- Comment: was deleted (was: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there.) > Statistics should be calculated using System.nanoTime instead of > System.currentTimeMillis. > -- > > Key: MRESOLVER-14 > URL: https://issues.apache.org/jira/browse/MRESOLVER-14 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MRESOLVER-14) Statistics should be calculated using System.nanoTime instead of System.currentTimeMillis.
[ https://issues.apache.org/jira/browse/MRESOLVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MRESOLVER-14. -- Resolution: Fixed > Statistics should be calculated using System.nanoTime instead of > System.currentTimeMillis. > -- > > Key: MRESOLVER-14 > URL: https://issues.apache.org/jira/browse/MRESOLVER-14 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MRESOLVER-11. -- Resolution: Fixed > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-11: > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MRESOLVER-11. -- Resolution: Fixed > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-11) Project dependency collection result should contain repositories.
[ https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MRESOLVER-11: --- Comment: was deleted (was: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there.) > Project dependency collection result should contain repositories. > - > > Key: MRESOLVER-11 > URL: https://issues.apache.org/jira/browse/MRESOLVER-11 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > > The resolution result provided when performing project dependency collection > is lacking the repositories from the collection request. Components the > project root node is passed to (transformers, for example), expect this > information to be provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-14) Statistics should be calculated using System.nanoTime instead of System.currentTimeMillis.
[ https://issues.apache.org/jira/browse/MRESOLVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942048#comment-15942048 ] Christian Schulte commented on MRESOLVER-14: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Statistics should be calculated using System.nanoTime instead of > System.currentTimeMillis. > -- > > Key: MRESOLVER-14 > URL: https://issues.apache.org/jira/browse/MRESOLVER-14 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-13) Exceptions are suppressed incorrectly when closing resources fails.
[ https://issues.apache.org/jira/browse/MRESOLVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942047#comment-15942047 ] Christian Schulte commented on MRESOLVER-13: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Exceptions are suppressed incorrectly when closing resources fails. > --- > > Key: MRESOLVER-13 > URL: https://issues.apache.org/jira/browse/MRESOLVER-13 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-14) Statistics should be calculated using System.nanoTime instead of System.currentTimeMillis.
[ https://issues.apache.org/jira/browse/MRESOLVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-14: Assignee: (was: Christian Schulte) > Statistics should be calculated using System.nanoTime instead of > System.currentTimeMillis. > -- > > Key: MRESOLVER-14 > URL: https://issues.apache.org/jira/browse/MRESOLVER-14 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-15) Dependency updates.
[ https://issues.apache.org/jira/browse/MRESOLVER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-15: Assignee: (was: Christian Schulte) > Dependency updates. > --- > > Key: MRESOLVER-15 > URL: https://issues.apache.org/jira/browse/MRESOLVER-15 > Project: Maven Resolver > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > > This issue gathers all commits changing dependency versions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.
[
https://issues.apache.org/jira/browse/MRESOLVER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942044#comment-15942044
]
Christian Schulte commented on MRESOLVER-10:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When
interested, you can cherry pick the commit to your own repository and create a
pull request for the apache master branch with just this commit yourself from
there.
> New class 'TransitiveDependencyManager' supporting transitive dependency
> management.
>
>
> Key: MRESOLVER-10
> URL: https://issues.apache.org/jira/browse/MRESOLVER-10
> Project: Maven Resolver
> Issue Type: New Feature
> Components: resolver
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from
> transitive dependencies to maintain backwards compatibility with Maven 2,
> then Maven 3 (objective when extracting Aether was to keep compatibility).
> The new {{TransitiveDependencyManager}} will use that dependency management:
> this new behaviour is expected to be a better choice.
> It could also be named {{DefaultDependencyManager}}, once it is integrated
> into Maven core (version to be defined) as default new behaviour = a
> behaviour that is more predictible/logical, but that will break some
> previously working builds.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.
[
https://issues.apache.org/jira/browse/MRESOLVER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MRESOLVER-10:
Assignee: (was: Christian Schulte)
> New class 'TransitiveDependencyManager' supporting transitive dependency
> management.
>
>
> Key: MRESOLVER-10
> URL: https://issues.apache.org/jira/browse/MRESOLVER-10
> Project: Maven Resolver
> Issue Type: New Feature
> Components: resolver
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from
> transitive dependencies to maintain backwards compatibility with Maven 2,
> then Maven 3 (objective when extracting Aether was to keep compatibility).
> The new {{TransitiveDependencyManager}} will use that dependency management:
> this new behaviour is expected to be a better choice.
> It could also be named {{DefaultDependencyManager}}, once it is integrated
> into Maven core (version to be defined) as default new behaviour = a
> behaviour that is more predictible/logical, but that will break some
> previously working builds.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management.
[ https://issues.apache.org/jira/browse/MRESOLVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942043#comment-15942043 ] Christian Schulte commented on MRESOLVER-9: --- Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > DefaultDependencyCollector does not correctly handle dependency management. > --- > > Key: MRESOLVER-9 > URL: https://issues.apache.org/jira/browse/MRESOLVER-9 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > > During dependency processing the 'DependencySelector' is called to decide if > a dependency is to be selected. The call to > 'DependencySelector.selectDependency( dependency )' is performed with the > unmanagement dependency but needs to be performed with the managed > dependency. With the fix applied, the result no longer contains dependencies > whose scope or optionality has been managed to not be part of the result > (correct behaviour). Without the fix applied, the result contains > dependencies with a managed scope or optionality not filtered out by the > 'DependencySelector' in use (incorrect behaviour). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management.
[ https://issues.apache.org/jira/browse/MRESOLVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MRESOLVER-9: --- Assignee: (was: Christian Schulte) > DefaultDependencyCollector does not correctly handle dependency management. > --- > > Key: MRESOLVER-9 > URL: https://issues.apache.org/jira/browse/MRESOLVER-9 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > > During dependency processing the 'DependencySelector' is called to decide if > a dependency is to be selected. The call to > 'DependencySelector.selectDependency( dependency )' is performed with the > unmanagement dependency but needs to be performed with the managed > dependency. With the fix applied, the result no longer contains dependencies > whose scope or optionality has been managed to not be part of the result > (correct behaviour). Without the fix applied, the result contains > dependencies with a managed scope or optionality not filtered out by the > 'DependencySelector' in use (incorrect behaviour). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-8) ScopeDependencySelector incorrectly de-selects direct dependencies.
[
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942042#comment-15942042
]
Christian Schulte commented on MRESOLVER-8:
---
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven-resolver/tree/master]. When
interested, you can cherry pick the commit to your own repository and create a
pull request for the apache master branch with just this commit yourself from
there.
> ScopeDependencySelector incorrectly de-selects direct dependencies.
> ---
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ScopeDependencySelector}} decides if a node is a direct dependency or
> transitive dependency differently based on the request performed. For the
> {{CollectRequest.setRootArtifact(Artifact)}} case, the class is working
> correctly. For the {{CollectRequest.setRoot(Dependency)}} case, the class is
> de-selecting direct dependencies instead of transitive dependencies.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-8) ScopeDependencySelector incorrectly de-selects direct dependencies.
[
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MRESOLVER-8:
---
Assignee: (was: Christian Schulte)
> ScopeDependencySelector incorrectly de-selects direct dependencies.
> ---
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ScopeDependencySelector}} decides if a node is a direct dependency or
> transitive dependency differently based on the request performed. For the
> {{CollectRequest.setRootArtifact(Artifact)}} case, the class is working
> correctly. For the {{CollectRequest.setRoot(Dependency)}} case, the class is
> de-selecting direct dependencies instead of transitive dependencies.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-6135:
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-5761: > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-5935: > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte > Fix For: 3.6.0-candidate > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5971:
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942040#comment-15942040
]
Christian Schulte commented on MNG-5639:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 3.2.2, 3.5.1-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5227:
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5639:
Assignee: (was: Jason van Zyl)
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 3.2.2, 3.5.1-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942038#comment-15942038 ] Christian Schulte commented on MNG-4347: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.1-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-4347: Assignee: (was: John Casey) > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.1-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5527:
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.1-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5600:
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5984:
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-6164:
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942030#comment-15942030
]
Christian Schulte commented on MNG-6135:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5761: -- Assignee: (was: Christian Schulte) > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6135:
--
Assignee: (was: Christian Schulte)
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942029#comment-15942029 ] Christian Schulte commented on MNG-5761: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942028#comment-15942028 ] Christian Schulte commented on MNG-5935: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte > Fix For: 3.6.0-candidate > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942027#comment-15942027
]
Christian Schulte commented on MNG-5227:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5935: -- Assignee: (was: Christian Schulte) > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte > Fix For: 3.6.0-candidate > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942026#comment-15942026
]
Christian Schulte commented on MNG-5971:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5227:
--
Assignee: (was: Christian Schulte)
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5971:
--
Assignee: (was: Christian Schulte)
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5600:
--
Assignee: (was: Christian Schulte)
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5527:
--
Assignee: (was: Christian Schulte)
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.1-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942024#comment-15942024
]
Christian Schulte commented on MNG-5527:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.1-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942025#comment-15942025
]
Christian Schulte commented on MNG-5600:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942019#comment-15942019 ] Christian Schulte commented on MNG-6114: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6164:
--
Assignee: (was: Christian Schulte)
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942021#comment-15942021
]
Christian Schulte commented on MNG-6164:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5984:
--
Assignee: (was: Christian Schulte)
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942018#comment-15942018
]
Christian Schulte commented on MNG-5984:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942016#comment-15942016 ] Christian Schulte commented on MNG-5359: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942012#comment-15942012 ] Christian Schulte commented on MNG-2893: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-625) Refactored to use 'maven-shared-utils' instead of 'plexus-utils'.
[ https://issues.apache.org/jira/browse/MSHARED-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-625: - Assignee: (was: Christian Schulte) > Refactored to use 'maven-shared-utils' instead of 'plexus-utils'. > -- > > Key: MSHARED-625 > URL: https://issues.apache.org/jira/browse/MSHARED-625 > Project: Maven Shared Components > Issue Type: Task > Components: maven-invoker >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-jarsigner-3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-624) Upgrade of maven-shared-utils to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-624: - Assignee: (was: Christian Schulte) > Upgrade of maven-shared-utils to 3.2.0. > --- > > Key: MSHARED-624 > URL: https://issues.apache.org/jira/browse/MSHARED-624 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-verifier-1.7 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-603) Upgrade maven-shared-resources to 2.
[ https://issues.apache.org/jira/browse/MSHARED-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-603: - Assignee: (was: Christian Schulte) > Upgrade maven-shared-resources to 2. > > > Key: MSHARED-603 > URL: https://issues.apache.org/jira/browse/MSHARED-603 > Project: Maven Shared Components > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-626) Upgrade of 'maven-shared-utils' to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-626: - Assignee: (was: Christian Schulte) > Upgrade of 'maven-shared-utils' to 3.2.0. > - > > Key: MSHARED-626 > URL: https://issues.apache.org/jira/browse/MSHARED-626 > Project: Maven Shared Components > Issue Type: Task > Components: maven-jarsigner >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-145) Upgrade maven-plugin-plugin to 3.5.
[ https://issues.apache.org/jira/browse/MPOM-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-145. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: ASF-19) > Upgrade maven-plugin-plugin to 3.5. > --- > > Key: MPOM-145 > URL: https://issues.apache.org/jira/browse/MPOM-145 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-143) Upgrade maven-dependency-plugin to 3.0.0.
[ https://issues.apache.org/jira/browse/MPOM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-143. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: ASF-19) > Upgrade maven-dependency-plugin to 3.0.0. > - > > Key: MPOM-143 > URL: https://issues.apache.org/jira/browse/MPOM-143 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-599) Escaping the escape string produces incorrect output.
[ https://issues.apache.org/jira/browse/MSHARED-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-599: - Assignee: (was: Christian Schulte) > Escaping the escape string produces incorrect output. > - > > Key: MSHARED-599 > URL: https://issues.apache.org/jira/browse/MSHARED-599 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-3.1.1 >Reporter: Christian Schulte > Fix For: maven-filtering-3.1.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-140) Upgrade maven-assembly-plugin to 3.0.0.
[ https://issues.apache.org/jira/browse/MPOM-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-140. -- Resolution: Duplicate Assignee: (was: Christian Schulte) > Upgrade maven-assembly-plugin to 3.0.0. > --- > > Key: MPOM-140 > URL: https://issues.apache.org/jira/browse/MPOM-140 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6184) Maven dependency StackOverflowException
[ https://issues.apache.org/jira/browse/MNG-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6184: -- Assignee: (was: Christian Schulte) > Maven dependency StackOverflowException > --- > > Key: MNG-6184 > URL: https://issues.apache.org/jira/browse/MNG-6184 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-alpha-1 >Reporter: Jon Harper > > See the last comments in MNG-5592 asking to reopen the issue. See the > attached file MNG-5592_testcase.zip -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6141: -- Assignee: (was: Christian Schulte) > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6079.
--
Resolution: Not A Problem
Fix Version/s: (was: 3.6.0-candidate)
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6114: -- Assignee: (was: Christian Schulte) > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6127: -- Assignee: (was: Christian Schulte) > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic > Fix For: needing-scrub-3.4.0-fallout > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6075. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: 3.6.0-candidate) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6079:
--
Assignee: (was: Christian Schulte)
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6073: -- Assignee: (was: Christian Schulte) > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6058) Test dependencies should override application dependencies only during testing.
[
https://issues.apache.org/jira/browse/MNG-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6058:
--
Assignee: (was: Christian Schulte)
> Test dependencies should override application dependencies only during
> testing.
> ---
>
> Key: MNG-6058
> URL: https://issues.apache.org/jira/browse/MNG-6058
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
> Attachments: MNG-6058.zip
>
>
> The following graph
> {code}
> POM
> |->a 2.0 compile
> |-->b 2.0 compile
> |->b 1.0 test
> {code}
> will be mediated to
> {code}
> POM
> |->a 2.0 compile
> |->b 1.0 test
> {code}
> The test dependency on b will make the transitive application dependency on b
> disappear. Maven should understand that the application dependency on b in
> version 2.0 is part of the application classpath and that the test
> dependency on b in version 1.0 is part of the test classpath only (overriding
> the application classpath). If someone adds a dependency on a project like
> that, the test dependency will disappear because the test scope is not
> transitive so that a "consuming" project gets a different application
> classpath than the project itself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6073. -- Resolution: Won't Fix Fix Version/s: (was: 3.6.0-candidate) > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6055) Move the release profile out of Maven's core so it can be more easily changed.
[ https://issues.apache.org/jira/browse/MNG-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6055: -- Assignee: (was: Christian Schulte) > Move the release profile out of Maven's core so it can be more easily changed. > -- > > Key: MNG-6055 > URL: https://issues.apache.org/jira/browse/MNG-6055 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5992) Git passwords are exposed as the Super POM still uses Maven Release Plugin 2.3.2
[ https://issues.apache.org/jira/browse/MNG-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5992: -- Assignee: (was: Christian Schulte) > Git passwords are exposed as the Super POM still uses Maven Release Plugin > 2.3.2 > > > Key: MNG-5992 > URL: https://issues.apache.org/jira/browse/MNG-5992 > Project: Maven > Issue Type: Improvement > Components: Bootstrap & Build, Plugins and Lifecycle, POM >Affects Versions: 3.3.3, 3.3.9 > Environment: All >Reporter: Ryan J. McDonough >Priority: Critical > Labels: security > Fix For: needing-scrub-3.4.0-fallout > > > The super POM defines version 2.3.2 of the Maven Release plugin. When using > HTTP/HTTPS Git SCM URIs, Maven will printout the password in the logs. Thus, > any CI system such as Jenkins, TravisCI, etc. will have the passwords exposed > in the logs and in the console output. In the case of TravisCI, this will be > publicly visible. > The [Maven Release Plugin fixed this issue in > MRELEASE-846|https://issues.apache.org/jira/browse/MRELEASE-846], but Maven > core is still pointing at an exposed version of the Maven Release plugin. I > have a test case that demonstrates the issue here: > https://github.com/damnhandy/maven-publish-issue > If you run the same build and explicitly define 2.5.3, the password is no > longer displayed. This should be the default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6054: -- Assignee: (was: Christian Schulte) > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6049:
--
Assignee: (was: Christian Schulte)
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5981:
--
Assignee: (was: Christian Schulte)
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5939: -- Assignee: (was: Christian Schulte) > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.3 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Fix For: needing-scrub-3.4.0-fallout > > Attachments: > 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5940:
--
Assignee: (was: Christian Schulte)
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: needing-scrub-3.4.0-fallout
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5863: -- Assignee: (was: Christian Schulte) > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka > Fix For: needing-scrub-3.4.0-fallout > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5359: -- Assignee: (was: Christian Schulte) > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://issues.apache.org/jira/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5708: -- Assignee: (was: Christian Schulte) > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://issues.apache.org/jira/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Fix For: needing-scrub-3.4.0-fallout > > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://issues.apache.org/jira/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5197: -- Assignee: (was: Christian Schulte) > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://issues.apache.org/jira/browse/MNG-5197 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Fix For: needing-scrub-3.4.0-fallout > > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-504) Update to latest Plexus Container
[ https://issues.apache.org/jira/browse/DOXIA-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942004#comment-15942004 ] Hudson commented on DOXIA-504: -- SUCCESS: Integrated in Jenkins build doxia-all #330 (See [https://builds.apache.org/job/doxia-all/330/]) [DOXIA-504] upgraded Plexus container to latest Submitted by: Mikolaj Izdebski (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1788692]) * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/module/AbstractIdentityTest.java * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/sink/impl/AbstractSinkTest.java * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/xsd/AbstractXmlValidator.java * (edit) ./doxia/pom.xml > Update to latest Plexus Container > - > > Key: DOXIA-504 > URL: https://issues.apache.org/jira/browse/DOXIA-504 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Mikolaj Izdebski > Attachments: doxia-plexus-container.patch > > > Doxia is currently using old alpha version of Plexus. Please update to > latest stable Plexus Container. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5222: -- Assignee: (was: Christian Schulte) > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Wish > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Priority: Minor > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-544) Set document tag on chapter header for FO format
[ https://issues.apache.org/jira/browse/DOXIA-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942003#comment-15942003 ] Hudson commented on DOXIA-544: -- SUCCESS: Integrated in Jenkins build doxia-all #330 (See [https://builds.apache.org/job/doxia-all/330/]) [DOXIA-544] set document tag on chapter header Submitted by: Blair Cooper (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1788693]) * (edit) ./doxia/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java > Set document tag on chapter header for FO format > > > Key: DOXIA-544 > URL: https://issues.apache.org/jira/browse/DOXIA-544 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - FO >Affects Versions: 1.7 >Reporter: Blair Cooper > Attachments: DoxiaFoPatch.txt > > > Currently the "id" tag is set on the block tag when starting the body. As a > result, if you're viewing the toc or bookmarks and you click on a chapter > title the document scrolls to the top of the body with the chapter title > scrolled off the top of the screen. > By setting the "id" on the block that starts the chapter heading the page > will scroll to a point where the chapter title is also visible. This provides > a better visual clue to the reader that they arrived at the desired location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-2478:
--
Assignee: (was: Christian Schulte)
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
> Fix For: needing-scrub-3.4.0-fallout
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-2893: -- Assignee: (was: Christian Schulte) > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MJAVADOC-462) Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1.
[ https://issues.apache.org/jira/browse/MJAVADOC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MJAVADOC-462: -- Assignee: (was: Christian Schulte) > Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1. > - > > Key: MJAVADOC-462 > URL: https://issues.apache.org/jira/browse/MJAVADOC-462 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.
[ https://issues.apache.org/jira/browse/MDOAP-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MDOAP-48: -- Assignee: (was: Christian Schulte) > Upgrade of plexus-interpolation to 1.24. > > > Key: MDOAP-48 > URL: https://issues.apache.org/jira/browse/MDOAP-48 > Project: Maven DOAP Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MARCHETYPES-48) Upgrade archetyp-packaging extension to 3.4.
[ https://issues.apache.org/jira/browse/MARCHETYPES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MARCHETYPES-48: Assignee: (was: Christian Schulte) > Upgrade archetyp-packaging extension to 3.4. > > > Key: MARCHETYPES-48 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-48 > Project: Maven Archetype Bundles > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MSITE-791) upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7)
[ https://issues.apache.org/jira/browse/MSITE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy resolved MSITE-791. - Resolution: Fixed Assignee: Hervé Boutemy > upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7) > - > > Key: MSITE-791 > URL: https://issues.apache.org/jira/browse/MSITE-791 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.7 > > > see DOXIA-554 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941999#comment-15941999
]
Hervé Boutemy commented on DOXIA-554:
-
Jira is the issues repository: you'll need to find an issue that you find
interest in
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6185) Replace doclettag explanation with annotations in AbstractMojo javadoc
[
https://issues.apache.org/jira/browse/MNG-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6185:
---
Assignee: Robert Scholte
> Replace doclettag explanation with annotations in AbstractMojo javadoc
> --
>
> Key: MNG-6185
> URL: https://issues.apache.org/jira/browse/MNG-6185
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.5.0
>
>
> The javadoc of {{org.apache.maven.plugin.AbstractMojo}} still describes the
> usage of doclettags, which should be upgraded/rewritten to annotations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5639:
---
Fix Version/s: 3.5.1-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2, 3.5.1-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
