You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-commits@incubator.apache.org by "John R. Fallows (JIRA)" <ji...@apache.org> on 2011/04/19 22:10:05 UTC
[jira] [Created] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Transitive dependency resolution requires explicit version in a dependent child pom
-----------------------------------------------------------------------------------
Key: NPANDAY-411
URL: https://issues.apache.org/jira/browse/NPANDAY-411
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-incubating
Environment: $ mvn -v
Apache Maven 2.2.1 (rdebian-4)
Java version: 1.6.0_24
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
Reporter: John R. Fallows
In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at npanday.dao.Project.hashCode(Project.java:329)
at java.util.HashMap.put(HashMap.java:372)
at java.util.HashSet.add(HashSet.java:200)
at npanday.dao.Project.addProjectDependency(Project.java:204)
at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "Brett Porter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated NPANDAY-411:
---------------------------------
Fix Version/s: 2.0
scheduling to go along with RDF removal
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.3.1-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
> Fix For: 2.0
>
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "John R. Fallows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021825#comment-13021825 ]
John R. Fallows commented on NPANDAY-411:
-----------------------------------------
Note that using an expression to describe the version, such as nunit.version fails as follows:
{code}
NPANDAY-1005-0001: Error copying dependency NUnit:NUnit.Framework:dotnet-library:${nunit.version}:test File /home/jfallows/.m2/repository/NUnit/NUnit.Framework/${nunit.version}/NUnit.Framework-${nunit.version}.dll does not exist
{code}
It seems as though the expression is not evaluated prior to constructing the artifact name.
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.3.1-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "Brennan Gaunce (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047746#comment-13047746 ]
Brennan Gaunce commented on NPANDAY-411:
----------------------------------------
In addition, it appears that properties cannot be used as versions, which increases the need for specifying the version in the parent pom for a large multi-module project.
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.4-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
> Fix For: 2.0
>
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "Lars Corneliussen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Corneliussen resolved NPANDAY-411.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0-incubating
Assignee: Lars Corneliussen
Fixed by NPANDAY-231
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.4-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
> Assignee: Lars Corneliussen
> Fix For: 1.5.0-incubating, 2.0
>
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "Brett Porter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022165#comment-13022165 ]
Brett Porter commented on NPANDAY-411:
--------------------------------------
The original issue was worked around, but the root issue is that NPanday doesn't use Maven's POM construction and resolution, but reproduces much of it it imperfectly. We're in a long process of removing that.
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.3.1-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "John R. Fallows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John R. Fallows updated NPANDAY-411:
------------------------------------
Description:
In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
{code}
WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at npanday.dao.Project.hashCode(Project.java:329)
at java.util.HashMap.put(HashMap.java:372)
at java.util.HashSet.add(HashSet.java:200)
at npanday.dao.Project.addProjectDependency(Project.java:204)
at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}
was:
In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at npanday.dao.Project.hashCode(Project.java:329)
at java.util.HashMap.put(HashMap.java:372)
at java.util.HashSet.add(HashSet.java:200)
at npanday.dao.Project.addProjectDependency(Project.java:204)
at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.3.1-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution
requires explicit version in a dependent child pom
Posted by "John R. Fallows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021863#comment-13021863 ]
John R. Fallows commented on NPANDAY-411:
-----------------------------------------
This issue reproduces both when the ThirdParty dependency is "test" scope _and_ when scope is omitted (default="compile" scope).
> Transitive dependency resolution requires explicit version in a dependent child pom
> -----------------------------------------------------------------------------------
>
> Key: NPANDAY-411
> URL: https://issues.apache.org/jira/browse/NPANDAY-411
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
> Affects Versions: 1.3.1-incubating
> Environment: $ mvn -v
> Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0_24
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
> Reporter: John R. Fallows
>
> In the past, NPanday required the version of a dependency in pom.xml to be explicit, whereas now that has been fixed so that a parent pom.xml can specify the version in the dependencyManagement section instead.
> Suppose we have 3 projects called Parent, Library and Executable. The Parent pom refers to both Library and Executable projects as modules, and also acts as the super pom for both Library and Executable projects. The Executable project depends on the Library project. The Parent project defaults the version of another dotnet-library (let's say ThirdParty) used by the Library project in the Parent's dependencyManagement section.
> The Library project builds successfully. However, when attempting to build the Executable project, it complains during dependency resolution that the version is missing from ThirdParty and the build fails. Now, while the version is physically missing from the Library pom.xml file, it is not missing from the effective pom for the Library and should therefore not give any error, just as no error is given when the Library project builds.
> {code}
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit, Artifact Id = NUnit.Framework
> [INFO] ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] null
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at npanday.dao.Project.hashCode(Project.java:329)
> at java.util.HashMap.put(HashMap.java:372)
> at java.util.HashSet.add(HashSet.java:200)
> at npanday.dao.Project.addProjectDependency(Project.java:204)
> at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
> at npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
> at npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
> at npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira