[jira] [Assigned] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5359: -- Assignee: (was: Christian Schulte) > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://issues.apache.org/jira/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5708: -- Assignee: (was: Christian Schulte) > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://issues.apache.org/jira/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Fix For: needing-scrub-3.4.0-fallout > > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://issues.apache.org/jira/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5197: -- Assignee: (was: Christian Schulte) > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://issues.apache.org/jira/browse/MNG-5197 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Fix For: needing-scrub-3.4.0-fallout > > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5222: -- Assignee: (was: Christian Schulte) > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Wish > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Priority: Minor > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-2478:
--
Assignee: (was: Christian Schulte)
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
> Fix For: needing-scrub-3.4.0-fallout
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-2893: -- Assignee: (was: Christian Schulte) > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MJAVADOC-462) Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1.
[ https://issues.apache.org/jira/browse/MJAVADOC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MJAVADOC-462: -- Assignee: (was: Christian Schulte) > Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1. > - > > Key: MJAVADOC-462 > URL: https://issues.apache.org/jira/browse/MJAVADOC-462 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.
[ https://issues.apache.org/jira/browse/MDOAP-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MDOAP-48: -- Assignee: (was: Christian Schulte) > Upgrade of plexus-interpolation to 1.24. > > > Key: MDOAP-48 > URL: https://issues.apache.org/jira/browse/MDOAP-48 > Project: Maven DOAP Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MARCHETYPES-48) Upgrade archetyp-packaging extension to 3.4.
[ https://issues.apache.org/jira/browse/MARCHETYPES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MARCHETYPES-48: Assignee: (was: Christian Schulte) > Upgrade archetyp-packaging extension to 3.4. > > > Key: MARCHETYPES-48 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-48 > Project: Maven Archetype Bundles > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5639:
---
Fix Version/s: 3.5.1-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2, 3.5.1-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (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 updated MNG-4347: --- Fix Version/s: 3.5.1-candidate > 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 >Assignee: 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] [Updated] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6164:
---
Fix Version/s: 3.5.1-candidate
> 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
> 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] [Updated] (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 updated MNG-5984:
---
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.1-candidate
> 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: 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] [Updated] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-2893: --- Fix Version/s: 3.5.1-candidate > 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 >Assignee: Christian Schulte > 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] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-2893: -- Assignee: Christian Schulte (was: Jason van Zyl) > 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 >Assignee: Christian Schulte > Fix For: 3.2.x > > > 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] [Closed] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6168. -- Resolution: Fixed Fix Version/s: (was: 3.5.0-candidate) 3.5.0 > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6168: -- Assignee: Christian Schulte > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (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:comment-tabpanel=15939431#comment-15939431
]
Christian Schulte commented on MNG-5868:
[~khmarbaise] will be working on this issue in the future. My initial attempt
was to simply throw an exception whenever an existing artifact is attached
again. That is what [~khmarbaise] had in mind as well. After doing this I
discovered quite a few issues in JIRA and just restored that behaviour. I
cannot tell what the final solution will be.
> 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: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> 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
[jira] [Closed] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.
[ https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6113. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: 3.5.0-candidate) > Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 > super POM. > - > > Key: MNG-6113 > URL: https://issues.apache.org/jira/browse/MNG-6113 > Project: Maven > Issue Type: Wish >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (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 closed MNG-6112. -- Resolution: Fixed Fix Version/s: (was: 3.5.0-candidate) 3.5.0 > 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 >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6190) maven-resolver-provider's DefaultArtifactDescriptorReader has mismatched constructor and initService methods
[
https://issues.apache.org/jira/browse/MNG-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6190.
--
Resolution: Fixed
Assignee: Christian Schulte
Fix Version/s: 3.5.0
The {{versionRangeResolver}} currently is only passed to the
{{DefaultModelResolver}}. It will be used there in 3.5.0 so this fixes a
potential {{NullPointerException}}. Thanks for reporting.
> maven-resolver-provider's DefaultArtifactDescriptorReader has mismatched
> constructor and initService methods
>
>
> Key: MNG-6190
> URL: https://issues.apache.org/jira/browse/MNG-6190
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.5.0-alpha-1
>Reporter: Laird Nelson
>Assignee: Christian Schulte
> Fix For: 3.5.0
>
>
> In {{DefaultArtifactDescriptorReader.java}}, the constructor annotated with
> {{@Inject}} differs in the parameters it takes from its {{initService()}}
> method.
> This discrepancy means among other things that its {{versionRangeResolver}}
> field is never initialized when a DI container is doing injection.
> Here is the relevant code, starting at line 112, with a comment where the
> problem is:
> {code}
> @Inject
> DefaultArtifactDescriptorReader( RemoteRepositoryManager
> remoteRepositoryManager, VersionResolver versionResolver,
> ArtifactResolver artifactResolver,
> ModelBuilder modelBuilder,
> RepositoryEventDispatcher
> repositoryEventDispatcher, LoggerFactory loggerFactory )
> {
> setRemoteRepositoryManager( remoteRepositoryManager );
> setVersionResolver( versionResolver );
> // XXX <-- Note: no versionRangeResolver
> setArtifactResolver( artifactResolver );
> setModelBuilder( modelBuilder );
> setLoggerFactory( loggerFactory );
> setRepositoryEventDispatcher( repositoryEventDispatcher );
> }
> public void initService( ServiceLocator locator )
> {
> setLoggerFactory( locator.getService( LoggerFactory.class ) );
> setRemoteRepositoryManager( locator.getService(
> RemoteRepositoryManager.class ) );
> setVersionResolver( locator.getService( VersionResolver.class ) );
> setVersionRangeResolver( locator.getService(
> VersionRangeResolver.class ) );
> setArtifactResolver( locator.getService( ArtifactResolver.class ) );
> setRepositoryEventDispatcher( locator.getService(
> RepositoryEventDispatcher.class ) );
> modelBuilder = locator.getService( ModelBuilder.class );
> if ( modelBuilder == null )
> {
> setModelBuilder( new DefaultModelBuilderFactory().newInstance() );
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6074.
--
Resolution: Not A Problem
Assignee: (was: Christian Schulte)
Fix Version/s: (was: 3.5.0-candidate)
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MRESOLVER-19) DefaultRepositorySystem resolveDependencies() can yield a NullPointerException
[
https://issues.apache.org/jira/browse/MRESOLVER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MRESOLVER-19.
--
Resolution: Fixed
Assignee: Christian Schulte
Fix Version/s: Maven Artifact Resolver 1.1.0
Thanks.
> DefaultRepositorySystem resolveDependencies() can yield a NullPointerException
> --
>
> Key: MRESOLVER-19
> URL: https://issues.apache.org/jira/browse/MRESOLVER-19
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Laird Nelson
>Assignee: Christian Schulte
> Fix For: Maven Artifact Resolver 1.1.0
>
>
> If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
> Starting from line 366:
> {code}
> ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
> DependencyFilter filter = request.getFilter();
> DependencyVisitor visitor = ( filter != null ) ? new
> FilteringDependencyVisitor( builder, filter ) : builder;
> visitor = new TreeDependencyVisitor( visitor );
> result.getRoot().accept( visitor ); // <-- if getRoot() is null: kaboom!
> List requests = builder.getRequests();
> {code}
> This is the relevant section of my code that causes the error:
> {code}
> final CollectRequest collectRequest = new CollectRequest();
> collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
> collectRequest.setRepositories(Collections.singletonList(mavenCentral));
> final DependencyRequest dependencyRequest = new
> DependencyRequest(collectRequest, classpathFilter);
> final DependencyResult dependencyResult =
> repositorySystem.resolveDependencies(repositorySystemSession,
> dependencyRequest);
> {code}
> From looking inside {{DefaultRepositorySystem.java}}, it looks like the
> collection result never gets its root set. At line 340 and following you see
> this:
> {code}
> if ( request.getRoot() != null )
> {
> result.setRoot( request.getRoot() );
> }
> else if ( request.getCollectRequest() != null )
> {
> CollectResult collectResult;
> try
> {
> request.getCollectRequest().setTrace( trace );
> collectResult = dependencyCollector.collectDependencies( session,
> request.getCollectRequest() );
> }
> catch ( DependencyCollectionException e )
> {
> dce = e;
> collectResult = e.getResult();
> }
> result.setRoot( collectResult.getRoot() );
> result.setCycles( collectResult.getCycles() );
> result.setCollectExceptions( collectResult.getExceptions() );
> }
> {code}
> Note in particular this line:
> {code}
> result.setRoot( collectResult.getRoot() );
> {code}
> Unless I'm missing something there's no guarantee that
> {{collectResult.getRoot()}} will be non-{{null}} if the collection request
> failed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MRESOLVER-19) DefaultRepositorySystem resolveDependencies() can yield a NullPointerException
[
https://issues.apache.org/jira/browse/MRESOLVER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MRESOLVER-19:
---
Summary: DefaultRepositorySystem resolveDependencies() can yield a
NullPointerException (was: DefaultRepositorySystem resolveDependencies() line
370 can yield a NullPointerException)
> DefaultRepositorySystem resolveDependencies() can yield a NullPointerException
> --
>
> Key: MRESOLVER-19
> URL: https://issues.apache.org/jira/browse/MRESOLVER-19
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Laird Nelson
>
> If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
> Starting from line 366:
> {code}
> ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
> DependencyFilter filter = request.getFilter();
> DependencyVisitor visitor = ( filter != null ) ? new
> FilteringDependencyVisitor( builder, filter ) : builder;
> visitor = new TreeDependencyVisitor( visitor );
> result.getRoot().accept( visitor ); // <-- if getRoot() is null: kaboom!
> List requests = builder.getRequests();
> {code}
> This is the relevant section of my code that causes the error:
> {code}
> final CollectRequest collectRequest = new CollectRequest();
> collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
> collectRequest.setRepositories(Collections.singletonList(mavenCentral));
> final DependencyRequest dependencyRequest = new
> DependencyRequest(collectRequest, classpathFilter);
> final DependencyResult dependencyResult =
> repositorySystem.resolveDependencies(repositorySystemSession,
> dependencyRequest);
> {code}
> From looking inside {{DefaultRepositorySystem.java}}, it looks like the
> collection result never gets its root set. At line 340 and following you see
> this:
> {code}
> if ( request.getRoot() != null )
> {
> result.setRoot( request.getRoot() );
> }
> else if ( request.getCollectRequest() != null )
> {
> CollectResult collectResult;
> try
> {
> request.getCollectRequest().setTrace( trace );
> collectResult = dependencyCollector.collectDependencies( session,
> request.getCollectRequest() );
> }
> catch ( DependencyCollectionException e )
> {
> dce = e;
> collectResult = e.getResult();
> }
> result.setRoot( collectResult.getRoot() );
> result.setCycles( collectResult.getCycles() );
> result.setCollectExceptions( collectResult.getExceptions() );
> }
> {code}
> Note in particular this line:
> {code}
> result.setRoot( collectResult.getRoot() );
> {code}
> Unless I'm missing something there's no guarantee that
> {{collectResult.getRoot()}} will be non-{{null}} if the collection request
> failed.
--
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 Fix Version/s: (was: Maven Artifact Resolver 1.2.0 pre-reset) Maven Artifact Resolver 1.1.0 > 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 >Assignee: 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 Fix Version/s: (was: Maven Artifact Resolver 1.2.0 pre-reset) Maven Artifact Resolver 1.1.0 > 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 >Assignee: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- 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: Re-opened to update fix version. > 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 >Assignee: Christian Schulte > Fix For: Maven Artifact Resolver 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MRESOLVER-18) DefaultDependencyCollector does not provide pre-managed state for exclusions and properties.
[ https://issues.apache.org/jira/browse/MRESOLVER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MRESOLVER-18. -- Resolution: Fixed Fix Version/s: Maven Artifact Resolver 1.1.0 > DefaultDependencyCollector does not provide pre-managed state for exclusions > and properties. > > > Key: MRESOLVER-18 > URL: https://issues.apache.org/jira/browse/MRESOLVER-18 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > 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 Fix Version/s: (was: Maven Artifact Resolver 1.2.0 pre-reset) Maven Artifact Resolver 1.1.0 > 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 >Assignee: 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-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: Re-opened to update fix version. > 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 >Assignee: Christian Schulte > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > -- 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: Re-opened to update fix version. > 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 >Assignee: 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] [Created] (MRESOLVER-18) DefaultDependencyCollector does not provide pre-managed state for exclusions and properties.
Christian Schulte created MRESOLVER-18: -- Summary: DefaultDependencyCollector does not provide pre-managed state for exclusions and properties. Key: MRESOLVER-18 URL: https://issues.apache.org/jira/browse/MRESOLVER-18 Project: Maven Resolver Issue Type: Improvement Reporter: Christian Schulte Assignee: Christian Schulte Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6183) Dependency management debug message corrections.
[
https://issues.apache.org/jira/browse/MNG-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6183:
---
Description:
When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
implementation of the {{ProjectDependenciesResolver}} interface logs debug
messages about what management has been applied during resolution. The messages
are lacking information about optionality, exclusions and properties (local
path) management and do not reflect the management performed by the resolver.
was:When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
implementation of the {{ProjectDependenciesResolver}} interface logs debug
messages about what management has been applied during resolution. Those debug
messages are incomplete and are lacking information about optional flag
management.
> Dependency management debug message corrections.
>
>
> Key: MNG-6183
> URL: https://issues.apache.org/jira/browse/MNG-6183
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
> implementation of the {{ProjectDependenciesResolver}} interface logs debug
> messages about what management has been applied during resolution. The
> messages are lacking information about optionality, exclusions and properties
> (local path) management and do not reflect the management performed by the
> resolver.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6183) Dependency management debug message corrections.
[
https://issues.apache.org/jira/browse/MNG-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6183:
---
Issue Type: Bug (was: Improvement)
> Dependency management debug message corrections.
>
>
> Key: MNG-6183
> URL: https://issues.apache.org/jira/browse/MNG-6183
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
> implementation of the {{ProjectDependenciesResolver}} interface logs debug
> messages about what management has been applied during resolution. Those
> debug messages are incomplete and are lacking information about optional flag
> management.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6183) Dependency management debug message corrections.
[
https://issues.apache.org/jira/browse/MNG-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6183:
---
Summary: Dependency management debug message corrections. (was: Dependency
management debug message enhancements.)
> Dependency management debug message corrections.
>
>
> Key: MNG-6183
> URL: https://issues.apache.org/jira/browse/MNG-6183
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
> implementation of the {{ProjectDependenciesResolver}} interface logs debug
> messages about what management has been applied during resolution. Those
> debug messages are incomplete and are lacking information about optional flag
> management.
--
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: 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 >Assignee: Christian Schulte > > 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] [Commented] (MNG-5592) Maven Dependency Resolution Locks up
[
https://issues.apache.org/jira/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902100#comment-15902100
]
Christian Schulte commented on MNG-5592:
Could you please create a new issue with just the failing test case producing a
{{StackOverflowError}}? I ran the test case and it seems the issue is not about
something locking up, but about the resolver throwing a {{StackOverflowError}}.
I can confirm this error is thrown with Maven 3.5.0-alpha-1 and
3.5.0-alpha-2-SNAPSHOT as well. I am just not sure the issue is related to the
original issue about lock ups which do not seem to happen with 3.5.0-alpha-1.
> Maven Dependency Resolution Locks up
>
>
> Key: MNG-5592
> URL: https://issues.apache.org/jira/browse/MNG-5592
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.1.1, 3.2.1
> Environment: OS/X, Java 7 and Java 8
>Reporter: Mark Derricutt
>Assignee: igorfie
> Fix For: 3.2.5
>
> Attachments: mng-5592-simplified.zip, MNG-5592_testcase.zip,
> mng-5592.zip, MNG-5592.zip
>
>
> One one of my larger integration projects that involves A LOT of version
> ranges across a broad range of dependencies I'm seeing that Maven locks up
> resolving dependencies.
> I've recently seen this in 3.1.1 but it's happening more and more often under
> 3.2.1.
> It appears that Eclipse Aether is falling into a circular loop somewhere and
> locking up.
> {code}
> "main" #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable
> [0x000103559000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145)
> at
> org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187)
> at
> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at
>
[jira] [Closed] (MNG-6183) Dependency management debug message enhancements.
[
https://issues.apache.org/jira/browse/MNG-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6183.
--
> Dependency management debug message enhancements.
> -
>
> Key: MNG-6183
> URL: https://issues.apache.org/jira/browse/MNG-6183
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
> implementation of the {{ProjectDependenciesResolver}} interface logs debug
> messages about what management has been applied during resolution. Those
> debug messages are incomplete and are lacking information about optional flag
> management.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6182) ModelResolver interface enhancements.
[
https://issues.apache.org/jira/browse/MNG-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6182.
--
> ModelResolver interface enhancements.
> --
>
> Key: MNG-6182
> URL: https://issues.apache.org/jira/browse/MNG-6182
> Project: Maven
> Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> In order to implement MNG-4463 in Maven 3.5.1, the {{ModelResolver}}
> interface needs to be enhanced. We will do that in Maven 3.5.0, but will not
> use any of the new methods. When e.g. IDE integrators upgrade to Maven 3.5.0,
> they will need to enhance theire implementations as of Maven 3.5.0 instead of
> Maven 3.5.1. This way we can avoid adding methods to public interfaces in a
> patch release Maven 3.5.1 and have a Maven 3.5.0 public API prepared for
> everything planned for 3.5.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-6183) Dependency management debug message enhancements.
[
https://issues.apache.org/jira/browse/MNG-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-6183.
Resolution: Fixed
> Dependency management debug message enhancements.
> -
>
> Key: MNG-6183
> URL: https://issues.apache.org/jira/browse/MNG-6183
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
> implementation of the {{ProjectDependenciesResolver}} interface logs debug
> messages about what management has been applied during resolution. Those
> debug messages are incomplete and are lacking information about optional flag
> management.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6183) Dependency management debug message enhancements.
Christian Schulte created MNG-6183:
--
Summary: Dependency management debug message enhancements.
Key: MNG-6183
URL: https://issues.apache.org/jira/browse/MNG-6183
Project: Maven
Issue Type: Improvement
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
Fix For: 3.5.0-alpha-2
When resolving dependencies, the {{DefaultProjectDependenciesResolver}}
implementation of the {{ProjectDependenciesResolver}} interface logs debug
messages about what management has been applied during resolution. Those debug
messages are incomplete and are lacking information about optional flag
management.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-6182) ModelResolver interface enhancements.
[
https://issues.apache.org/jira/browse/MNG-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-6182.
Resolution: Fixed
> ModelResolver interface enhancements.
> --
>
> Key: MNG-6182
> URL: https://issues.apache.org/jira/browse/MNG-6182
> Project: Maven
> Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0-alpha-2
>
>
> In order to implement MNG-4463 in Maven 3.5.1, the {{ModelResolver}}
> interface needs to be enhanced. We will do that in Maven 3.5.0, but will not
> use any of the new methods. When e.g. IDE integrators upgrade to Maven 3.5.0,
> they will need to enhance theire implementations as of Maven 3.5.0 instead of
> Maven 3.5.1. This way we can avoid adding methods to public interfaces in a
> patch release Maven 3.5.1 and have a Maven 3.5.0 public API prepared for
> everything planned for 3.5.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6182) ModelResolver interface enhancements.
Christian Schulte created MNG-6182:
--
Summary: ModelResolver interface enhancements.
Key: MNG-6182
URL: https://issues.apache.org/jira/browse/MNG-6182
Project: Maven
Issue Type: New Feature
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
Fix For: 3.5.0-alpha-2
In order to implement MNG-4463 in Maven 3.5.1, the {{ModelResolver}} interface
needs to be enhanced. We will do that in Maven 3.5.0, but will not use any of
the new methods. When e.g. IDE integrators upgrade to Maven 3.5.0, they will
need to enhance theire implementations as of Maven 3.5.0 instead of Maven
3.5.1. This way we can avoid adding methods to public interfaces in a patch
release Maven 3.5.1 and have a Maven 3.5.0 public API prepared for everything
planned for 3.5.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6173) MavenSession.getAllProjects() should return all projects in the reactor
[
https://issues.apache.org/jira/browse/MNG-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6173.
--
Resolution: Fixed
Fix Version/s: 3.5.0-alpha-2
Modified the patch to move {{MavenSession}} object initialization out of
{{DefaultGraphBuilder}} and extended the {{ProjectDependencyGraph}} interface
to support querying all collected projects.
> MavenSession.getAllProjects() should return all projects in the reactor
> ---
>
> Key: MNG-6173
> URL: https://issues.apache.org/jira/browse/MNG-6173
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Christoph Böhme
>Assignee: Christian Schulte
> Fix For: 3.5.0-alpha-2
>
>
> According to MNG-5582 {{MavenSession.getAllProjects()}} should return all
> projects in the reactor even if the set is constrained by {{--projects}}. The
> current implementation, however, returns the same constrained list that is
> returned by {{MavenSession.getProjects()}}.
> This bug seems to have been introduced when MNG-5775 was implemented.
> I came across this bug when I tried to fix [an
> issue|https://github.com/mojohaus/flatten-maven-plugin/issues/26] in the
> flatten-maven-plugin. In order to solve the issue a list of all projects in
> the reactor is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6173) MavenSession.getAllProjects() should return all projects in the reactor
[
https://issues.apache.org/jira/browse/MNG-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6173:
--
Assignee: Christian Schulte
> MavenSession.getAllProjects() should return all projects in the reactor
> ---
>
> Key: MNG-6173
> URL: https://issues.apache.org/jira/browse/MNG-6173
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Christoph Böhme
>Assignee: Christian Schulte
>
> According to MNG-5582 {{MavenSession.getAllProjects()}} should return all
> projects in the reactor even if the set is constrained by {{--projects}}. The
> current implementation, however, returns the same constrained list that is
> returned by {{MavenSession.getProjects()}}.
> This bug seems to have been introduced when MNG-5775 was implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6173) MavenSession.getAllProjects() should return all projects in the reactor
[
https://issues.apache.org/jira/browse/MNG-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15895835#comment-15895835
]
Christian Schulte commented on MNG-6173:
Thank you very much. There is [a
discussion|http://www.mail-archive.com/dev@maven.apache.org/msg112962.html]
ongoing on dev@. I'll paste the relevant part here so that things can be
discussed here.
bq. Hervé BOUTEMY Sat, 04 Mar 2017 09:55:27 -0800 I have one question, which
is recurring for every issue: what is the impact? I understand the logic: it
should fix a bug (that is told introduced in Maven 3.3.1), and the bug is
explained by the logic behind the javadoc. But no pointer to any code using
this method, and that shows that Maven 3.3.1 does not work any more, when
previous version were ok. Then what is explained here as a bugfix could cause
issues for others. I'm -1 unless I have some details on the impact. Regards,
Hervé
> MavenSession.getAllProjects() should return all projects in the reactor
> ---
>
> Key: MNG-6173
> URL: https://issues.apache.org/jira/browse/MNG-6173
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Christoph Böhme
>
> According to MNG-5582 {{MavenSession.getAllProjects()}} should return all
> projects in the reactor even if the set is constrained by {{--projects}}. The
> current implementation, however, returns the same constrained list that is
> returned by {{MavenSession.getProjects()}}.
> This bug seems to have been introduced when MNG-5775 was implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6173) MavenSession.getAllProjects() should return all projects in the reactor
[
https://issues.apache.org/jira/browse/MNG-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892084#comment-15892084
]
Christian Schulte commented on MNG-6173:
Would be cool if you could open a pull request against the
maven-integration-testing repository providing integration tests for the issue.
> MavenSession.getAllProjects() should return all projects in the reactor
> ---
>
> Key: MNG-6173
> URL: https://issues.apache.org/jira/browse/MNG-6173
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Christoph Böhme
>
> According to MNG-5582 {{MavenSession.getAllProjects()}} should return all
> projects in the reactor even if the set is constrained by {{--projects}}. The
> current implementation, however, returns the same constrained list that is
> returned by {{MavenSession.getProjects()}}.
> This bug seems to have been introduced when MNG-5775 was implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MSHARED-626) Upgrade of 'maven-shared-utils' to 3.2.0.
Christian Schulte created MSHARED-626: - Summary: 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 Assignee: Christian Schulte Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (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 updated MSHARED-625: -- Fix Version/s: maven-jarsigner-3.0.0 > 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 >Assignee: Christian Schulte >Priority: Trivial > Fix For: maven-jarsigner-3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-625) Refactored to use 'maven-shared-utils' instead of 'plexus-utils'.
Christian Schulte created MSHARED-625: - Summary: 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 Assignee: Christian Schulte Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-624) Upgrade of maven-shared-utils to 3.2.0.
Christian Schulte created MSHARED-624: - Summary: 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 Assignee: Christian Schulte Priority: Trivial Fix For: maven-verifier-1.7 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-623) Deprecation of methods 'close' and 'flush' of class 'StreamPumper'.
[ https://issues.apache.org/jira/browse/MSHARED-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-623. - Resolution: Fixed Assignee: Christian Schulte > Deprecation of methods 'close' and 'flush' of class 'StreamPumper'. > --- > > Key: MSHARED-623 > URL: https://issues.apache.org/jira/browse/MSHARED-623 > Project: Maven Shared Components > Issue Type: Task > Components: maven-shared-utils >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: maven-shared-utils-3.2.0 > > > The methods are a legacy of 'plexus-utils' but are no longer needed in > 'maven-shared-utils' where they are no-ops. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-623) Deprecation of methods 'close' and 'flush' of class 'StreamPumper'.
Christian Schulte created MSHARED-623: - Summary: Deprecation of methods 'close' and 'flush' of class 'StreamPumper'. Key: MSHARED-623 URL: https://issues.apache.org/jira/browse/MSHARED-623 Project: Maven Shared Components Issue Type: Task Components: maven-shared-utils Reporter: Christian Schulte Priority: Trivial Fix For: maven-shared-utils-3.2.0 The methods are a legacy of 'plexus-utils' but are no longer needed in 'maven-shared-utils' where they are no-ops. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-620) CommandLineCallable should defer starting threads until called.
[ https://issues.apache.org/jira/browse/MSHARED-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-620. - Resolution: Fixed > CommandLineCallable should defer starting threads until called. > --- > > Key: MSHARED-620 > URL: https://issues.apache.org/jira/browse/MSHARED-620 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-621) CommandLineCallable should calculate process timeouts using 'System.nanoTime' instead of 'System.currentTimeMillis'.
[ https://issues.apache.org/jira/browse/MSHARED-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-621. - Resolution: Fixed > CommandLineCallable should calculate process timeouts using 'System.nanoTime' > instead of 'System.currentTimeMillis'. > > > Key: MSHARED-621 > URL: https://issues.apache.org/jira/browse/MSHARED-621 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-622) CommandLineCallable silently ignores exceptions thrown from the stdin processor (StreemFeeder).
[ https://issues.apache.org/jira/browse/MSHARED-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-622. - Resolution: Fixed > CommandLineCallable silently ignores exceptions thrown from the stdin > processor (StreemFeeder). > --- > > Key: MSHARED-622 > URL: https://issues.apache.org/jira/browse/MSHARED-622 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-618) CommandLineCallable does not always call the 'runAfterProcessTermination' runnable.
[ https://issues.apache.org/jira/browse/MSHARED-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-618. - Resolution: Fixed > CommandLineCallable does not always call the 'runAfterProcessTermination' > runnable. > --- > > Key: MSHARED-618 > URL: https://issues.apache.org/jira/browse/MSHARED-618 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-622) CommandLineCallable silently ignores exceptions thrown from the stdin processor (StreemFeeder).
Christian Schulte created MSHARED-622: - Summary: CommandLineCallable silently ignores exceptions thrown from the stdin processor (StreemFeeder). Key: MSHARED-622 URL: https://issues.apache.org/jira/browse/MSHARED-622 Project: Maven Shared Components Issue Type: Bug Reporter: Christian Schulte Assignee: Christian Schulte Fix For: maven-shared-utils-3.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-621) CommandLineCallable should calculate process timeouts using 'System.nanoTime' instead of 'System.currentTimeMillis'.
Christian Schulte created MSHARED-621: - Summary: CommandLineCallable should calculate process timeouts using 'System.nanoTime' instead of 'System.currentTimeMillis'. Key: MSHARED-621 URL: https://issues.apache.org/jira/browse/MSHARED-621 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Christian Schulte Assignee: Christian Schulte Fix For: maven-shared-utils-3.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-620) CommandLineCallable should defer starting threads until called.
Christian Schulte created MSHARED-620: - Summary: CommandLineCallable should defer starting threads until called. Key: MSHARED-620 URL: https://issues.apache.org/jira/browse/MSHARED-620 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Christian Schulte Assignee: Christian Schulte Fix For: maven-shared-utils-3.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-619) StreamFeeder silently ignores exceptions.
[ https://issues.apache.org/jira/browse/MSHARED-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-619. - Resolution: Fixed > StreamFeeder silently ignores exceptions. > - > > Key: MSHARED-619 > URL: https://issues.apache.org/jira/browse/MSHARED-619 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MSHARED-617) StreamFeeder should flush OutputStream
[ https://issues.apache.org/jira/browse/MSHARED-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MSHARED-617. - Resolution: Fixed Assignee: Christian Schulte (was: Tibor Digana) Fix Version/s: (was: maven-shared-utils-0.9.1) maven-shared-utils-3.2.0 > StreamFeeder should flush OutputStream > -- > > Key: MSHARED-617 > URL: https://issues.apache.org/jira/browse/MSHARED-617 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Tibor Digana >Assignee: Christian Schulte > Fix For: maven-shared-utils-3.2.0 > > > The class StreamFeeder should flush the OutputStream after line 127. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MSHARED-617) StreamFeeder should flush OutputStream
[ https://issues.apache.org/jira/browse/MSHARED-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MSHARED-617: -- Summary: StreamFeeder should flush OutputStream (was: (FreeBSD) StreamFeeder.java should flush OutputStream) > StreamFeeder should flush OutputStream > -- > > Key: MSHARED-617 > URL: https://issues.apache.org/jira/browse/MSHARED-617 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: maven-shared-utils-0.9.1 > > > The class StreamFeeder should flush the OutputStream after line 127. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-619) StreamFeeder silently ignores exceptions.
Christian Schulte created MSHARED-619: - Summary: StreamFeeder silently ignores exceptions. Key: MSHARED-619 URL: https://issues.apache.org/jira/browse/MSHARED-619 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Reporter: Christian Schulte Assignee: Christian Schulte Fix For: maven-shared-utils-3.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MSHARED-618) CommandLineCallable does not always call the 'runAfterProcessTermination' runnable.
Christian Schulte created MSHARED-618: - Summary: CommandLineCallable does not always call the 'runAfterProcessTermination' runnable. Key: MSHARED-618 URL: https://issues.apache.org/jira/browse/MSHARED-618 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Reporter: Christian Schulte Assignee: Christian Schulte Fix For: maven-shared-utils-3.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6178) --file does not work when the target path contains "special" characters like space and
[ https://issues.apache.org/jira/browse/MNG-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6178. -- Resolution: Duplicate Assignee: (was: Christian Schulte) Fix Version/s: (was: 3.5.0-alpha-2) > --file does not work when the target path contains "special" characters like > space and & > > > Key: MNG-6178 > URL: https://issues.apache.org/jira/browse/MNG-6178 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0-alpha-1 >Reporter: Christian Schulte > > The launcher scripts forgot to quote correctly, here is the fix: > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=37b5f27080006883613800127d70e8233210555e -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6177) The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
[ https://issues.apache.org/jira/browse/MNG-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6177. -- Resolution: Fixed > The --file command line option of the Windows and Unix launchers does not > work for directory names like "Spaces & Special Char" > --- > > Key: MNG-6177 > URL: https://issues.apache.org/jira/browse/MNG-6177 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-alpha-1 >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Fix For: 3.5.0-alpha-2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6177) The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
Christian Schulte created MNG-6177: -- Summary: The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char" Key: MNG-6177 URL: https://issues.apache.org/jira/browse/MNG-6177 Project: Maven Issue Type: Bug Affects Versions: 3.5.0-alpha-1 Reporter: Christian Schulte Assignee: Christian Schulte Priority: Critical Fix For: 3.5.0-alpha-2 -- 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=15849304#comment-15849304
]
Christian Schulte commented on MNG-5600:
See [this
thread|http://www.mail-archive.com/dev@maven.apache.org/msg112480.html] on
dev@. Issue is resolved, not closed.
> 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] [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=15849302#comment-15849302
]
Christian Schulte commented on MNG-6135:
See [this
thread|http://www.mail-archive.com/dev@maven.apache.org/msg112480.html] on
dev@. Issue is resolved, not closed.
> 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] [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] (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] [Closed] (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 closed MNG-5883.
--
Resolution: Fixed
> 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
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0
>
>
> 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.3.4#6332)
[jira] [Updated] (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 updated MNG-5883:
---
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0
> 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
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.5.0
>
>
> 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.3.4#6332)
[jira] [Updated] (MNG-5670) ConcurrentModificationException during DefaultMaven.newRepositorySession
[ https://issues.apache.org/jira/browse/MNG-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-5670: --- Fix Version/s: (was: 3.5.0-candidate) 3.5.0 > ConcurrentModificationException during DefaultMaven.newRepositorySession > > > Key: MNG-5670 > URL: https://issues.apache.org/jira/browse/MNG-5670 > Project: Maven > Issue Type: Bug > Components: Embedding >Reporter: Igor Fedorenko >Assignee: Guillaume Boué > Fix For: 3.2.3, 3.5.0 > > > DefaultMaven.newRepositorySession will fail with > ConcurrentModificationException if System.properties is modified concurrently > by another thread. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=439227 > for original bug report against m2e. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15826943#comment-15826943
]
Christian Schulte commented on MNG-5958:
The changes to the core integration testing repository have been discussed on
dev@. See the following threads.
[\[IT MNG-5958\]: Please review integration test for
MNG-5958|http://www.mail-archive.com/dev@maven.apache.org/msg112133.html]
[\[IT MNG-5958 - Take 2\]: Please review integration test for
MNG-5958|http://www.mail-archive.com/dev@maven.apache.org/msg112212.html]
> 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;
>
[jira] [Updated] (MNG-5962) mvn fails when the current directory has spaces in between
[
https://issues.apache.org/jira/browse/MNG-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5962:
---
Assignee: Michael Osipov
> mvn fails when the current directory has spaces in between
> --
>
> Key: MNG-5962
> URL: https://issues.apache.org/jira/browse/MNG-5962
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3, 3.3.9
> Environment: Windows 7
>Reporter: Miriam Lee
>Assignee: Michael Osipov
>Priority: Minor
> Labels: easyfix, newbie
> Fix For: 3.5.0
>
> Attachments: MNG-5962-apache-maven.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Executing {{mvn.cmd}} when the current directory has spaces in between
> outputs {{The system cannot find the path specified.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6056) Implement Feature Toggle Module to handle Feature Toggles
[
https://issues.apache.org/jira/browse/MNG-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6056:
---
Fix Version/s: (was: 3.5.0)
> Implement Feature Toggle Module to handle Feature Toggles
> -
>
> Key: MNG-6056
> URL: https://issues.apache.org/jira/browse/MNG-6056
> Project: Maven
> Issue Type: Task
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Attachments: knob.jpg
>
>
> Implement a feature toggle module to handle feature toggles in Maven. The
> best from my point of view at the moment is having a relationship to the JIRA
> which defines all kinds of bugs, issues and of course features.
> Create a separate module: {{maven-feature}} to have no other dependency which
> means it can be integrated into any other module of maven.
> Add appropriate command line option like {{--activate-features}} to activate
> one or more features in one go. This prevents us from changing the command
> line every time we add or remove a feature toggle.
> So a command line option could look like this:
> {code}
> mvn --activate-features MNG2345,MNG1299 clean package
> {code}
> This will activate the features {{MNG2345}} and {{MNG1299}}. If you try to
> activate a feature toggle which does not exist we should simply print out a
> warning and just continue. This will simplify also future changes which means
> if 3.4.0 introduces a feature toggle {{MNG-}} but in Maven 3.5.0 this
> feature toggle does not exists anymore or made default calling the command
> line that way will only produce a warning nothing more.
> It should be compile time save which means if the feature toggle will be
> removed the compiler should show where this features has been used or
> questioned if it is activated. This will simplify the removal of the
> dependent code.
> Simplify adding of new feature toggles.
> Currently the best seemed to be an enumeration which contains this
> information.
> It should also be possible to list all available feature toggles via command
> line option like {{--list-features}} which should print out the existing
> feature toggles plus an appropriate description for the user (in particular
> intended for maven devs).
> It should also be simple to query for a feature toggle like:
> {code:java}
> @Requirement
> private SelectedFeatures featureToggle;
> ...
> if (featureToggle.isFeatureActive(Feature.MNG1)) {
> // The feature is implemented here or a different selection is done.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5837:
---
Assignee: Michael Osipov (was: Christian Schulte)
> Syntax error in bin/mvn on Solaris SPARC
>
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>Assignee: Michael Osipov
> Fix For: 3.5.0-candidate
>
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `('
> unexpected{code}
> Looks like similas issues as in MNG-5658
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5823) mvnDebug doesn't work with M2_HOME with spaces - missing quotes
[
https://issues.apache.org/jira/browse/MNG-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5823:
---
Assignee: Michael Osipov (was: Christian Schulte)
> mvnDebug doesn't work with M2_HOME with spaces - missing quotes
> ---
>
> Key: MNG-5823
> URL: https://issues.apache.org/jira/browse/MNG-5823
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1
> Environment: Windows, Cygwin
>Reporter: Tobias Oberlies
>Assignee: Michael Osipov
> Fix For: 3.5.0-candidate
>
>
> When calling {{mvnDebug}} in a Cygwin shell, I get the following error
> {noformat}
> Preparing to Execute Maven in Debug Mode
> dirname: extra operand `Files/Maven/apache-maven-3.3.1/bin/mvnDebug'
> Try `dirname --help' for more information.
> env: /mvn: No such file or directory
> {noformat}
> The root cause are missing quotes in and around the dirname call. The script
> currently calls
> {noformat}
> env MAVEN_OPTS="$MAVEN_OPTS $MAVEN_DEBUG_OPTS" $(dirname $0)/mvn "$@"
> {noformat}
> but the call should be
> {noformat}
> env MAVEN_OPTS="$MAVEN_OPTS $MAVEN_DEBUG_OPTS" "$(dirname "$0")/mvn" "$@"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5670) ConcurrentModificationException during DefaultMaven.newRepositorySession
[ https://issues.apache.org/jira/browse/MNG-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-5670: --- Assignee: Guillaume Boué (was: igorfie) > ConcurrentModificationException during DefaultMaven.newRepositorySession > > > Key: MNG-5670 > URL: https://issues.apache.org/jira/browse/MNG-5670 > Project: Maven > Issue Type: Bug > Components: Embedding >Reporter: Igor Fedorenko >Assignee: Guillaume Boué > Fix For: 3.2.3, 3.5.0-candidate > > > DefaultMaven.newRepositorySession will fail with > ConcurrentModificationException if System.properties is modified concurrently > by another thread. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=439227 > for original bug report against m2e. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6110) Upgrade Aether to Maven Resolver
[ https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-6110: --- Assignee: Hervé Boutemy (was: Christian Schulte) > 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.4#6332)
[jira] [Updated] (MNG-5962) mvn fails when the current directory has spaces in between
[
https://issues.apache.org/jira/browse/MNG-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5962:
---
Assignee: (was: Christian Schulte)
> mvn fails when the current directory has spaces in between
> --
>
> Key: MNG-5962
> URL: https://issues.apache.org/jira/browse/MNG-5962
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3, 3.3.9
> Environment: Windows 7
>Reporter: Miriam Lee
>Priority: Minor
> Labels: easyfix, newbie
> Fix For: 3.5.0
>
> Attachments: MNG-5962-apache-maven.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Executing {{mvn.cmd}} when the current directory has spaces in between
> outputs {{The system cannot find the path specified.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6053) Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
[
https://issues.apache.org/jira/browse/MNG-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6053:
---
Assignee: Guillaume Boué (was: Christian Schulte)
> Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
> -
>
> Key: MNG-6053
> URL: https://issues.apache.org/jira/browse/MNG-6053
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
> Environment: Eclipse m2e 1.7
>Reporter: Fred Bricon
>Assignee: Guillaume Boué
> Fix For: 3.5.0
>
>
> This bug has been reported in m2e
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=493871:
> {quote}
> I'm occasionally, not 100% reliably reproducible, but regularly enough (like
> it occurs every now and then, not just once) seeing the error below, in the
> Error Log of Eclipse during workspace rebuilds. This is with M2E 1.7.0. --
> I'm not sure if this is just "annoying" or actually prevents M2E from
> correctly configuring projects (?). Either way, perhaps it would be possible
> to "harden" respective code to prevent this?
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession(MavenRepositorySystemUtils.java:133)
> at
> org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession(DefaultRepositorySystemSessionFactory.java:98)
> at
> org.apache.maven.DefaultMaven.newRepositorySession(DefaultMaven.java:352)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.createRepositorySession(MavenImpl.java:309)
> {quote}
> Looking at
> https://github.com/apache/maven/blob/86b656167923923e2e416def4a48303b4e6248fa/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java#L132,
> it seems some system property is null (maybe due to some concurrency issue),
> and given that Hashtable doesn't support null values, then it throws an NPE
> on the put() call
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
