[jira] [Updated] (MRESOLVER-43) Enhancements to the public API to add support for tracking various informational declaration source hints.
[ https://issues.apache.org/jira/browse/MRESOLVER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MRESOLVER-43: --- Description: The Maven Core uses various Maven Resolver API DependencyVisitor implementations to provide debug level messages displaying final resolution results provided by the Maven Resolver. In order to decouple those debug messages from Maven Resolver internal implementation details, the Maven Resolver API needs to be enhanced to provide more information like informational hints to declaration sources. Please see the example log file about how the final debug messages provided by Maven Core could look like. All this information is provided by Maven Resolver without Maven Core having any knowledge about Maven Resolver implementation internals any more. (was: The Maven Core implements various Maven Resolver API DependencVisitor interfaces to provide debug level messages displaying final resolution results provided by the Maven Resolver. In order to decouple those debug messages from Maven Resolver internal implementation details, the Maven Resolver API needs to be enhanced to provide more information like informational hints to declaration sources. Please see the example log file about how the final debug messages provided by Maven Core could look like. All this information is provided by Maven Resolver without Maven Core having any knowledge about Maven Resolver implementation internals any more.) > Enhancements to the public API to add support for tracking various > informational declaration source hints. > -- > > Key: MRESOLVER-43 > URL: https://issues.apache.org/jira/browse/MRESOLVER-43 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Attachments: example.log > > > The Maven Core uses various Maven Resolver API DependencyVisitor > implementations to provide debug level messages displaying final resolution > results provided by the Maven Resolver. In order to decouple those debug > messages from Maven Resolver internal implementation details, the Maven > Resolver API needs to be enhanced to provide more information like > informational hints to declaration sources. Please see the example log file > about how the final debug messages provided by Maven Core could look like. > All this information is provided by Maven Resolver without Maven Core having > any knowledge about Maven Resolver implementation internals any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-43) Enhancements to the public API to add support for tracking various informational declaration source hints.
[ https://issues.apache.org/jira/browse/MRESOLVER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MRESOLVER-43: --- Attachment: example.log > Enhancements to the public API to add support for tracking various > informational declaration source hints. > -- > > Key: MRESOLVER-43 > URL: https://issues.apache.org/jira/browse/MRESOLVER-43 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Attachments: example.log > > > The Maven Core uses various Maven Resolver API DependencyVisitor > implementations to provide debug level messages displaying final resolution > results provided by the Maven Resolver. In order to decouple those debug > messages from Maven Resolver internal implementation details, the Maven > Resolver API needs to be enhanced to provide more information like > informational hints to declaration sources. Please see the example log file > about how the final debug messages provided by Maven Core could look like. > All this information is provided by Maven Resolver without Maven Core having > any knowledge about Maven Resolver implementation internals any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRESOLVER-43) Enhancements to the public API to add support for tracking various informational declaration source hints.
Christian Schulte created MRESOLVER-43: -- Summary: Enhancements to the public API to add support for tracking various informational declaration source hints. Key: MRESOLVER-43 URL: https://issues.apache.org/jira/browse/MRESOLVER-43 Project: Maven Resolver Issue Type: Improvement Components: resolver Reporter: Christian Schulte Assignee: Christian Schulte The Maven Core implements various Maven Resolver API DependencVisitor interfaces to provide debug level messages displaying final resolution results provided by the Maven Resolver. In order to decouple those debug messages from Maven Resolver internal implementation details, the Maven Resolver API needs to be enhanced to provide more information like informational hints to declaration sources. Please see the example log file about how the final debug messages provided by Maven Core could look like. All this information is provided by Maven Resolver without Maven Core having any knowledge about Maven Resolver implementation internals any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6161) Dependencies' management via import should take precedence over inherited definitions
[ https://issues.apache.org/jira/browse/MNG-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6161. -- Resolution: Duplicate > Dependencies' management via import should take precedence > over inherited definitions > > > Key: MNG-6161 > URL: https://issues.apache.org/jira/browse/MNG-6161 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) > Maven home: /usr/local/Cellar/maven/3.3.9/libexec > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.2", arch: "x86_64", family: "mac" >Reporter: Daniel McGreal >Priority: Major > > Hi, I would like to suggest an improvement to the way in which > import dependencies are handled. > Currently, if I have four projects: > * 'version' which sets a dependency on X with a version of Y, and is a parent > pom > * 'depender' which inherits from 'version' and declares a dependency on X > * 'provider' which manages X to scope provided > * 'last' which depends on 'depender' and imports 'provider's managed > dependencies > then the 'provider' definition is ignored and 'version's is chosen. > The use case I'm trying to achieve is where some dependencies are excluded > from a plugin's activities, and using provided is the best way > for me to achieve this. Using import to override > hierarchically defined dependency management would be a nice way of > organising this in a way that supports the multi-tired architecture my real > use case would require. > In short, it feels to me that a definition with > import should be 'closer' to the current bundle's dependency > resolution than its parents. > Thanks for your consideration, > Dan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6246) Inconsistent override behaivor with BOM vs dependency
[ https://issues.apache.org/jira/browse/MNG-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6246. -- Resolution: Duplicate > Inconsistent override behaivor with BOM vs dependency > - > > Key: MNG-6246 > URL: https://issues.apache.org/jira/browse/MNG-6246 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.5.0 > Environment: osx jdk 1.8 >Reporter: Jay mann >Priority: Major > Attachments: mvn-bug.tar.gz > > > Consider we have 2 BOM files: > bom1 - dependency version 1 > bom2 - dependency version 2' > When a bom1 is imported into a parent and bom2 is imported into a child of > parernt, child correctly overrides the dependency and uses "verision 2". > When parent does not import bom1 but explicitly states "dependency 1" in the > section, and child imports bom2, "version 1" of > dependency is used (bom2 in child does not override the dependency) > This seems like inconsistent behavior as documentation explains that a BOM > basically imports the section of the bom into the > current pom. > If this is expected behavior it should be documented as we recently moved all > our dependencyManagement section into a BOM for organizational reasons and it > did not work as expected. > Attached is a sample, to test simply extract and run: > mvn install -f bom1/pom.xml > mvn install -f bom2/pom.xml > mvn dependency:tree -f project/child/pom.xml > mvn dependency:tree -f project2/child/pom.xml > project uses bom in parent and child and is overridden correctly. > project2 parent uses dependency instead of bom, child uses bom but dependency > is NOT overridden. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343167#comment-16343167 ] Christian Schulte edited comment on MNG-6284 at 1/29/18 10:16 AM: -- Closing this "Not A Problem". Just watch out for MNG-5359 if things seem confusing. was (Author: schulte77): Closing this "Not A Problem". Just watch out for MNG-5339 if things seem confusing. > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick >Priority: Major > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6284. -- Resolution: Not A Problem Closing this "Not A Problem". Just watch out for MNG-5339 if things seem confusing. > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick >Priority: Major > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16267797#comment-16267797
]
Christian Schulte commented on MNG-6141:
[~ctrueden] Everything regarding those commits will lead to endless discussions
and nothing else. Sad about the situation is that the most interesting issues
solved in that repository are re-reported by independent users in JIRA again
and again. Discussions were about "existing, experienced, senior" users having
become used to things as they are vs. "new, unexperienced, junior" users
reporting issues in JIRA senior users decided to either never resolve or to
postpone to a new Maven major version. I stopped any discussions when I was
told that Maven would not be my personal playground although the only thing I
did was resolving those JIRA issues reported by users. Breathtaking colors had
higher priority. Hmpf. Forget about that one ;-)
> 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-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, 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 from inside a {{}} element 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 that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel=16266502#comment-16266502
]
Christian Schulte commented on MNG-6141:
FWIW I put a lot of effort into sorting out things like this during development
of Maven 3.4.0. Nearly a year of work. All of this effort has been reverted and
the master branch got reset. Personally I am still using that Maven version, of
course. It is behaving differently but in a way I (and the users having
reported the issues in JIRA) expect Maven to behave by default. It is available
in my forked [Maven repository|https://github.com/ChristianSchulte/maven] and
[Maven resolver repository|https://github.com/ChristianSchulte/maven-resolver]
on Github. I am keeping the version at 3.4.0-SNAPSHOT so to not introduce any
confusion. You can also grab a [binary
release|https://github.com/ChristianSchulte/maven/releases/download/2017-11-27/apache-maven-3.4.0-SNAPSHOT-bin.zip]
in case you are interested to see how your projects behave with quite a lot of
issues resolved not released and never to be released because of corrections to
dependency resolution changing behaviour. It includes fixes for what this issue
is about. Using that Maven, I seldomly stumble upon projects running into such
corner cases without noticing and help them fix things.
> 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-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, 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 from inside a {{}} element 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 that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5883:
--
Assignee: (was: Christian Schulte)
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5739) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://issues.apache.org/jira/browse/MNG-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226076#comment-16226076
]
Christian Schulte commented on MNG-5739:
[~nadavwe] There has been some discussion about this on dev@ and some ongoing
proposals for how to deal with this in an upcoming model version. Haven't
followed any discussions for a few months. Issue will be taken care of. Last
time it was something about "support different classpaths per project rather
than just one - e.g. test and compile where test overrides compile". There has
been consensus that this issue cannot be dealed with in model version 4.0.0.
> Adding a test dependency can move dependencies from the compile scope to the
> test scope
> ---
>
> Key: MNG-5739
> URL: https://issues.apache.org/jira/browse/MNG-5739
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Andy Wilkinson
> Fix For: needing-scrub-3.4.0-fallout
>
> Attachments: pom.xml, test-scope-problem.zip
>
>
> I'm seeing some strange behaviour where the transitive dependencies of a
> test-scope dependency are causing transitive dependencies of a compile-scope
> dependency to become test-scoped.
> A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
> the following dependencies:
> {noformat}
> $ mvn dependency:tree | grep org.eclipse.jetty:
> [INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
> [INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
> [INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
> [INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
> [INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
> [INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
> [INFO] +-
> org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
> [INFO] \-
> org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
> [INFO]\-
> org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
> {noformat}
> If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
> dependencies that were previously in the compile scope are now in the test
> scope:
> {noformat}
> $ mvn dependency:tree | grep org.eclipse.jetty:
> [INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
> [INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
> [INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
> [INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
> [INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
> [INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
> {noformat}
> My understanding is that this is because the shortest route to the root of
> the hierarchy wins and, for a number of the Jetty dependencies, the shortest
> route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
> a test-scoped dependency being upgraded to the compile scope when a
> dependency is added, but downgrading a dependency from the compile scope to
> the test scope feels broken to me.
> I can work around the problem by using dependency management to force the
> dependencies into the compile scope, or by declaring direct dependencies on
> the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
> approaches require me to know what all those dependencies are and "duplicate"
> them in my pom, undermining the value of the dependencies being pulled in
> transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (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 updated MNG-6141:
---
Description:
Overriding the dependency management in a module's {{}} section,
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
from inside a {{}} element 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 that way without
noticing this is not supported transitively.
was:
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.
> 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's {{}}
> section, 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 from inside a {{}} element 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 that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MRESOLVER-33) New class 'DefaultDependencyManager' managing dependencies on all levels supporting transitive dependency management.
Christian Schulte created MRESOLVER-33:
--
Summary: New class 'DefaultDependencyManager' managing
dependencies on all levels supporting transitive dependency management.
Key: MRESOLVER-33
URL: https://issues.apache.org/jira/browse/MRESOLVER-33
Project: Maven Resolver
Issue Type: New Feature
Reporter: Christian Schulte
Priority: Trivial
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 {{TransitiveDependencyManager}} will use that dependency management and
will still support management overrides from inside {{}}
elements. See the linked issues.
The {{DefaultDependencyManager}} will no longer support such overrides and can
be considered the default implementation from a resolver point of view.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (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 updated MRESOLVER-10:
---
Description:
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. 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.
was:
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.
> 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. 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.4.14#64029)
[jira] [Commented] (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:comment-tabpanel=16214155#comment-16214155
]
Christian Schulte commented on MNG-6141:
[~joehni] To not introduce any misunderstandings. This issue is about
overriding dependency management locally within a module's {{}}
section. Such overrides are only in effect locally during building the module
and nowhere else - not even in the same reactor. See the attached example
project. You could override the dependency management inside
{{}} in a consistent way, though.
> 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.4.14#64029)
[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)
