[jira] [Commented] (MNG-6140) update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
[ https://issues.apache.org/jira/browse/MNG-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848078#comment-15848078 ] Hudson commented on MNG-6140: - FAILURE: Integrated in Jenkins build maven-3.x #1535 (See [https://builds.apache.org/job/maven-3.x/1535/]) [MNG-6140] renamed aether to resolver, added slf4j-provider (hboutemy: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=1cb2e92b5ad6bc2baa80c48b6357d5f42df4e48f]) * (edit) src/site/xdoc/index.xml * (edit) src/site/resources/images/maven-deps.png * (edit) src/site/xdoc/maven-deps.odg > update documentation's dependency graph with resolver + resolver-provider + > slf4j-provider > -- > > Key: MNG-6140 > URL: https://issues.apache.org/jira/browse/MNG-6140 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > http://maven.apache.org/ref/3-LATEST/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6110) Upgrade Aether to Maven Resolver
[ https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848079#comment-15848079 ] Hudson commented on MNG-6110: - FAILURE: Integrated in Jenkins build maven-3.x #1535 (See [https://builds.apache.org/job/maven-3.x/1535/]) [MNG-6110] Upgrade Aether to Maven Resolver 1.0.3 (hboutemy: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=4d6c9292c433626fa0b9a1cf711d4d0c366e7f33]) * (edit) pom.xml * (edit) maven-compat/pom.xml * (edit) apache-maven/pom.xml * (edit) maven-aether-provider/pom.xml * (edit) maven-embedder/pom.xml * (edit) maven-core/pom.xml [MNG-6110] renamed 'maven-aether-provider' to 'maven-resolver-provider' (hboutemy: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=8972072e3200e2ecfe2acb6d0b2dc40b10a6bc31]) * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java * (delete) maven-aether-provider/src/test/resources/repo/org/apache/maven/its/dep-mng5324/07.20.3-SNAPSHOT/maven-metadata.xml * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegate.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegate.java * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelCache.java * (delete) maven-aether-provider/src/site/apt/index.apt * (add) maven-resolver-provider/src/test/resources/repo/ut/simple/artifact/1.0/artifact-1.0-classifier.zip * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/ArtifactDescriptorUtils.java * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/LocalSnapshotMetadataGenerator.java * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenSnapshotMetadata.java * (edit) pom.xml * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/VersionsMetadata.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/LocalSnapshotMetadataGenerator.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/VersionsMetadata.java * (add) maven-resolver-provider/src/test/resources/repo/ut/simple/artifact/1.0/artifact-1.0.zip * (add) maven-resolver-provider/src/test/resources/repo/ut/simple/dependency/1.0/dependency-1.0.pom * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenWorkspaceReader.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenMetadata.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenAetherModule.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java * (delete) maven-aether-provider/src/test/resources/repo/ut/simple/artifact/maven-metadata.xml * (add) maven-resolver-provider/src/test/resources/repo/ut/simple/dependency/1.0/dependency-1.0.jar * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadataGenerator.java * (delete) maven-aether-provider/src/test/java/org/apache/maven/repository/internal/RemoteSnapshotMetadataTest.java * (edit) maven-core/pom.xml * (add) maven-resolver-provider/pom.xml * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenAetherModule.java * (delete) maven-aether-provider/src/test/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReaderTest.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java * (add) maven-resolver-provider/src/site/site.xml * (delete) maven-aether-provider/src/test/java/org/apache/maven/repository/internal/util/ConsoleRepositoryListener.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/SnapshotMetadataGeneratorFactory.java * (add) maven-resolver-provider/src/test/resources/repo/ut/simple/artifact/maven-metadata.xml * (add) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenResolverModule.java * (delete) maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelResolver.java * (add)
[jira] [Commented] (MNG-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848077#comment-15848077
]
Hudson commented on MNG-5878:
-
FAILURE: Integrated in Jenkins build maven-3.x #1535 (See
[https://builds.apache.org/job/maven-3.x/1535/])
[MNG-5878] added project.directory property to support module name !=
(hboutemy:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=9b763cc002e9a4e247baf7538727da5a29a6ce0b])
* (add)
maven-model-builder/src/test/resources/poms/inheritance/module-path-not-artifactId-parent.xml
* (add)
maven-model-builder/src/test/resources/poms/inheritance/module-path-not-artifactId-child.xml
* (edit) maven-model/src/main/mdo/maven.mdo
* (edit)
maven-model-builder/src/test/java/org/apache/maven/model/inheritance/DefaultInheritanceAssemblerTest.java
* (edit) maven-model-builder/src/site/apt/index.apt
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java
* (add)
maven-model-builder/src/test/resources/poms/inheritance/module-path-not-artifactId-expected.xml
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-5878.
--
Resolution: Fixed
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6110) Upgrade Aether to Maven Resolver
[ https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MNG-6110. -- Resolution: Fixed > Upgrade Aether to Maven Resolver > > > Key: MNG-6110 > URL: https://issues.apache.org/jira/browse/MNG-6110 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.3.9 >Reporter: Harald Wellmann >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > Replace Aether by Maven Resolver to make use of the latest bugfixes and > enhancements related to dependency collection. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6140) update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
[ https://issues.apache.org/jira/browse/MNG-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MNG-6140. -- Resolution: Fixed > update documentation's dependency graph with resolver + resolver-provider + > slf4j-provider > -- > > Key: MNG-6140 > URL: https://issues.apache.org/jira/browse/MNG-6140 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > http://maven.apache.org/ref/3-LATEST/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (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 updated MNG-5600:
---
Fix Version/s: (was: 3.6.0-candidate)
3.5.1-candidate
> 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
>Assignee: Christian Schulte
> 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] [Updated] (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 updated MNG-5527:
---
Fix Version/s: (was: 3.6.0-candidate)
3.5.1-candidate
> 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
>Assignee: Christian Schulte
> 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] [Resolved] (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 resolved MNG-6135.
Resolution: Fixed
> 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
>Assignee: 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] [Resolved] (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 resolved MNG-5600.
Resolution: Fixed
> 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
>Assignee: Christian Schulte
> Fix For: 3.6.0-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] [Closed] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5958.
--
Resolution: Fixed
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.5.0
>
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> {noformat}[ERROR] Internal error: java.lang.ClassCastException:
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more{noformat}
> I didn’t see anyone encountering the same problem. Maybe it is related to the
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> {code:java}LifecyclePhase goals =
> goalsForLifecyclePhase.getValue();{code}
> this is the content of the pom.xml:
> {code:xml}http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
>
>com.myapp.plugin
> GUI
> trunk
>
> myapp-war
> 1.0
> war
> Plugin GUI WAR
>
> myapp-ui
>
>
>
[jira] [Resolved] (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 resolved MNG-5935. Resolution: Fixed > 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 >Assignee: Christian Schulte > 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] [Resolved] (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 resolved MNG-5761. Resolution: Fixed > 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 >Assignee: Christian Schulte >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] [Resolved] (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 resolved MNG-5227.
Resolution: Fixed
> 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
>Assignee: 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] [Updated] (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 updated MNG-5227:
---
Summary: The 'optional' flag of a dependency should be manageable. (was:
Make 'optional' flag of a dependency manageable.)
> 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
>Assignee: 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] [Resolved] (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 resolved MNG-5971.
Resolution: Fixed
> 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
>Assignee: Christian Schulte
>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] [Resolved] (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 resolved MNG-5527.
Resolution: Fixed
> 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
>Assignee: Christian Schulte
> Fix For: 3.6.0-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] [Resolved] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte resolved MNG-5359. Resolution: Fixed > 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 >Assignee: Christian Schulte > Fix For: 3.5.0-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] [Resolved] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-5868.
Resolution: Fixed
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: needing-scrub-3.4.0-fallout
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (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 resolved MNG-5984.
Resolution: Fixed
> 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
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: needing-scrub-3.4.0-fallout
>
>
> 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] [Resolved] (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 resolved MNG-6114. Resolution: Fixed > 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 >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-6164.
Resolution: Fixed
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>
> 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] [Created] (MNG-6164) Collections inconsistently immutable.
Christian Schulte created MNG-6164:
--
Summary: Collections inconsistently immutable.
Key: MNG-6164
URL: https://issues.apache.org/jira/browse/MNG-6164
Project: Maven
Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Critical
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] (ARCHETYPE-440) Additional goals specified through goals param should be added to any goals specified by the used archetype
[ https://issues.apache.org/jira/browse/ARCHETYPE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847637#comment-15847637 ] Hudson commented on ARCHETYPE-440: -- SUCCESS: Integrated in Jenkins build maven-archetype-m3 #254 (See [https://builds.apache.org/job/maven-archetype-m3/254/]) [ARCHETYPE-440] Additional goals specified through goals param should be (rfscholte: rev db50d01a1c74bb31afc1e38207cda7782bd0dc74) * (edit) maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java > Additional goals specified through goals param should be added to any goals > specified by the used archetype > --- > > Key: ARCHETYPE-440 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-440 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator > Environment: n/a >Reporter: Anders Hammar >Assignee: Robert Scholte > > Any goals specified through the 'goals' param are only executed if no goals > are specified by the archetype itself. Based on the description of the param > this is wrong as it says "additional goals". Any specified goals should be > executed in addition to the ones specified by the used archetype. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (ARCHETYPE-440) Additional goals specified through goals param should be added to any goals specified by the used archetype
[
https://issues.apache.org/jira/browse/ARCHETYPE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed ARCHETYPE-440.
Resolution: Invalid
Assignee: Robert Scholte
Fix Version/s: (was: 3.0.0)
The text is misleading. Is states _additional_, whereas goals are never stored
as part of the archetype in the catalog ('goals' is marked as transient), hence
goals are never additional.
I've adjusted the text in
[db50d01a1c74bb31afc1e38207cda7782bd0dc74|http://git-wip-us.apache.org/repos/asf/maven-archetype/commit/db50d01a]
to prevent future confusion.
> Additional goals specified through goals param should be added to any goals
> specified by the used archetype
> ---
>
> Key: ARCHETYPE-440
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-440
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Robert Scholte
>
> Any goals specified through the 'goals' param are only executed if no goals
> are specified by the archetype itself. Based on the description of the param
> this is wrong as it says "additional goals". Any specified goals should be
> executed in addition to the ones specified by the used archetype.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5368) UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
[
https://issues.apache.org/jira/browse/MNG-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847597#comment-15847597
]
Hudson commented on MNG-5368:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1534 (See
[https://builds.apache.org/job/maven-3.x/1534/])
[MNG-5368] UnsupportedOperationException thrown when version range is (schulte:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=a3cdfbbbe9dcbd2737e3b4c1836c402f5d83ed46])
* (edit)
maven-compat/src/main/java/org/apache/maven/repository/legacy/LegacyRepositorySystem.java
> UnsupportedOperationException thrown when version range is not correct in
> dependencyManagement definitions
> --
>
> Key: MNG-5368
> URL: https://issues.apache.org/jira/browse/MNG-5368
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.4
> Environment: MacOS 10.7.5 Darwin Kernel Version 11.4.2:
> xnu-1699.32.7~1/RELEASE_X86_64 x86_64
>Reporter: Andrew Haines
>Assignee: Christian Schulte
> Fix For: 3.5.0
>
>
> When specifying a non valid version range in a dependencyManagement tag,
> instead of a descriptive error message we get a UnsupportedOperationException
> thrown. The code at fault in
> org.apache.maven.project.MavenProject#getManagedVersionMap is:
> {code}
> map = new HashMap();
> for ( Iterator i =
> dependencyManagement.getDependencies().iterator(); i.hasNext(); )
> {
> Dependency d = i.next();
> Artifact artifact =
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}
> When the artifact is null, the map is set to an immutable map and then the
> null artifact is then attempted to be put into it. This will always fail.
> This particular problem originates from code further down the stack in
> org.apache.maven.repository.legacy.LegacyRepositorySystem:
> {code}
>public Artifact createDependencyArtifact( Dependency d )
> {
> VersionRange versionRange;
> try
> {
> versionRange = VersionRange.createFromVersionSpec( d.getVersion()
> );
> }
> catch ( InvalidVersionSpecificationException e )
> {
> return null;
> }
> {code}
> Instead of signalling appropriately that an error has occurred, this
> exception is consumed and thus causes the erroneous behaviour mentioned in
> the first code snippet
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5368) UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
[
https://issues.apache.org/jira/browse/MNG-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5368.
--
Resolution: Fixed
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0
> UnsupportedOperationException thrown when version range is not correct in
> dependencyManagement definitions
> --
>
> Key: MNG-5368
> URL: https://issues.apache.org/jira/browse/MNG-5368
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.4
> Environment: MacOS 10.7.5 Darwin Kernel Version 11.4.2:
> xnu-1699.32.7~1/RELEASE_X86_64 x86_64
>Reporter: Andrew Haines
>Assignee: Christian Schulte
> Fix For: 3.5.0
>
>
> When specifying a non valid version range in a dependencyManagement tag,
> instead of a descriptive error message we get a UnsupportedOperationException
> thrown. The code at fault in
> org.apache.maven.project.MavenProject#getManagedVersionMap is:
> {code}
> map = new HashMap();
> for ( Iterator i =
> dependencyManagement.getDependencies().iterator(); i.hasNext(); )
> {
> Dependency d = i.next();
> Artifact artifact =
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}
> When the artifact is null, the map is set to an immutable map and then the
> null artifact is then attempted to be put into it. This will always fail.
> This particular problem originates from code further down the stack in
> org.apache.maven.repository.legacy.LegacyRepositorySystem:
> {code}
>public Artifact createDependencyArtifact( Dependency d )
> {
> VersionRange versionRange;
> try
> {
> versionRange = VersionRange.createFromVersionSpec( d.getVersion()
> );
> }
> catch ( InvalidVersionSpecificationException e )
> {
> return null;
> }
> {code}
> Instead of signalling appropriately that an error has occurred, this
> exception is consumed and thus causes the erroneous behaviour mentioned in
> the first code snippet
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5878:
---
Fix Version/s: (was: 3.5.0-candidate)
3.5.0
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847550#comment-15847550 ] Arnaud HERITIER commented on MNG-6037: -- what does it mean [~hboutemy]? Still no colorised console for Maven ?!? It's a running gag ... ??? > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: needing-scrub-3.4.0-fallout > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847547#comment-15847547 ] Hervé Boutemy commented on MNG-6037: I won't merge it if nobody asks for it > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: needing-scrub-3.4.0-fallout > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847543#comment-15847543
]
ASF GitHub Bot commented on MNG-5961:
-
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
Cool @michael-o it is exactly what I did
the build is in progress
https://builds.apache.org/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-5961/
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (SUREFIRE-1312) Classpath containing url special characters with Reflections not working
[
https://issues.apache.org/jira/browse/SUREFIRE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847529#comment-15847529
]
Tibor Digana commented on SUREFIRE-1312:
[~yanicks90]
We had an internal collision and I tried to recover from this and reverted 11
commits and now trying to fix them and add the last jira fix and then cut the
release version. Please try to be patient. We want to continue on this project.
> Classpath containing url special characters with Reflections not working
>
>
> Key: SUREFIRE-1312
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1312
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.16
> Environment: windows 7, RHEL 7
>Reporter: Yanick Salzmann
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> When using the maven surefire plugin with unit tests that make use of the
> {{CdiRunner}} (which internally fires up a Weld context) I am facing problems
> with classpaths that contain characters that need url encoding.
> I have created the following debug output in my test class in the
> {{@BeforeClass}} method:
> {code}
> System.out.println("WELD-TEST");
> System.out.println(ConverterTest.class.getClassLoader().getResource("."));
> System.out.println("WELD-TEST-END");
> {code}
> This prints the following output:
> {{file:/C:/sources%402/parser/target/test-classes/}}
> When the tests are launched from IntelliJ the output looks like this:
> {{file:/C:/sources@2/parser/target/test-classes/}}
> Note the @2 versus %402. In the end this causes Reflections (used by Weld) to
> fail, because it attempts to urlencode the classpath and ends up with
> {{file:/C:/sources%25402/parser/target/test-classes/}} and gets exceptions
> when attempting to read files and directories.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6136) Upgrade Maven Wagon to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847511#comment-15847511 ] Hudson commented on MNG-6136: - SUCCESS: Integrated in Jenkins build maven-3.x #1533 (See [https://builds.apache.org/job/maven-3.x/1533/]) [MNG-6136] Upgrade Maven Wagon to 2.12 (michaelo: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=ce93bb42b95c097ce7671576ae9e780b5a2bc653]) * (edit) pom.xml > Upgrade Maven Wagon to 2.12 > --- > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > Let's absorb latest improvements to Wagon into Maven. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-6137) Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
[
https://issues.apache.org/jira/browse/MNG-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847512#comment-15847512
]
Hudson commented on MNG-6137:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1533 (See
[https://builds.apache.org/job/maven-3.x/1533/])
[MNG-6137] Clean up duplicate dependencies caused by incomplete Wagon
(michaelo:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=23b5fcffa75b89e5c3141be5269840d6cd70fe12])
* (edit) apache-maven/pom.xml
> Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider
> exclusions
> ---
>
> Key: MNG-6137
> URL: https://issues.apache.org/jira/browse/MNG-6137
> Project: Maven
> Issue Type: Task
> Components: Deployment
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Some dependencies are duplicated in {{$\{maven.home}/lib}} because not all
> shaded dependencies of Wagon HTTP Provider are excluded. This can easily be
> cleaned up when Wagon 2.12 is merged.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847510#comment-15847510 ] Michael Osipov commented on MNG-6037: - Hervé, aren't we going to drop this? > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: needing-scrub-3.4.0-fallout > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-6137) Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
[
https://issues.apache.org/jira/browse/MNG-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6137.
---
Resolution: Fixed
Fixed with
[23b5fcffa75b89e5c3141be5269840d6cd70fe12|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=23b5fcffa75b89e5c3141be5269840d6cd70fe12].
> Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider
> exclusions
> ---
>
> Key: MNG-6137
> URL: https://issues.apache.org/jira/browse/MNG-6137
> Project: Maven
> Issue Type: Task
> Components: Deployment
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Some dependencies are duplicated in {{$\{maven.home}/lib}} because not all
> shaded dependencies of Wagon HTTP Provider are excluded. This can easily be
> cleaned up when Wagon 2.12 is merged.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6136) Upgrade Maven Wagon to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6136. --- Resolution: Fixed Fixed with [ce93bb42b95c097ce7671576ae9e780b5a2bc653|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=ce93bb42b95c097ce7671576ae9e780b5a2bc653]. > Upgrade Maven Wagon to 2.12 > --- > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > Let's absorb latest improvements to Wagon into Maven. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847497#comment-15847497
]
ASF GitHub Bot commented on MNG-5961:
-
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/104
Do this:
git checkout master
git checkout -b MNG-5961
git cherry-pick
git push
Wait for the Jenkins build to finish, get approval
git checkout master
git merge MNG-5961
Delete branch locally and remote.
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847458#comment-15847458
]
ASF GitHub Bot commented on MNG-5961:
-
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
@michael-o we don't have a CI validation here, thus I have to open a real
branch on ASF side. Right ?
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847441#comment-15847441
]
ASF GitHub Bot commented on MNG-5961:
-
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/104
I am fine with this PR. You have to raise the issue on the dev mailing list
to have at least someone who seconds it. If someone does, after your branch
passes all tests, go ahead and merge into master.
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6137) Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
[
https://issues.apache.org/jira/browse/MNG-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6137:
Fix Version/s: (was: 3.5.0-candidate)
3.5.0
> Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider
> exclusions
> ---
>
> Key: MNG-6137
> URL: https://issues.apache.org/jira/browse/MNG-6137
> Project: Maven
> Issue Type: Task
> Components: Deployment
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Some dependencies are duplicated in {{$\{maven.home}/lib}} because not all
> shaded dependencies of Wagon HTTP Provider are excluded. This can easily be
> cleaned up when Wagon 2.12 is merged.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6136) Upgrade Maven Wagon to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6136: Fix Version/s: (was: 3.5.0-candidate) 3.5.0 > Upgrade Maven Wagon to 2.12 > --- > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > Let's absorb latest improvements to Wagon into Maven. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847432#comment-15847432
]
ASF GitHub Bot commented on MNG-5961:
-
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
I think @stephenc will tell me to push a branch on ASF side :-)
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847431#comment-15847431
]
ASF GitHub Bot commented on MNG-5961:
-
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
cc @michael-o @stephenc
https://issues.apache.org/jira/browse/MNG-5961
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MINVOKER-217) Upgrade to maven-invoker shared component release version 3.0.0
[ https://issues.apache.org/jira/browse/MINVOKER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847370#comment-15847370 ] Hudson commented on MINVOKER-217: - SUCCESS: Integrated in Jenkins build maven-plugins #8727 (See [https://builds.apache.org/job/maven-plugins/8727/]) [MINVOKER-217] Upgrade to maven-invoker shared component release version 3.0.0 (khmarbaise: [http://svn.apache.org/viewvc/?view=rev=1781149]) * (edit) maven-invoker-plugin/pom.xml > Upgrade to maven-invoker shared component release version 3.0.0 > --- > > Key: MINVOKER-217 > URL: https://issues.apache.org/jira/browse/MINVOKER-217 > Project: Maven Invoker Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MINVOKER-217) Upgrade to maven-invoker shared component release version 3.0.0
[ https://issues.apache.org/jira/browse/MINVOKER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINVOKER-217. Resolution: Fixed Done in [r1781149|https://svn.apache.org/r1781149] > Upgrade to maven-invoker shared component release version 3.0.0 > --- > > Key: MINVOKER-217 > URL: https://issues.apache.org/jira/browse/MINVOKER-217 > Project: Maven Invoker Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (MINVOKER-217) Upgrade to maven-invoker shared component release version 3.0.0
Karl Heinz Marbaise created MINVOKER-217: Summary: Upgrade to maven-invoker shared component release version 3.0.0 Key: MINVOKER-217 URL: https://issues.apache.org/jira/browse/MINVOKER-217 Project: Maven Invoker Plugin Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Blocker Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
