[jira] [Commented] (NPANDAY-411) Transitive dependency resolution requires explicit version in a dependent child pom
[
https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution requires explicit version in a dependent child pom
[
https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution requires explicit version in a dependent child pom
[
https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
