[jira] (MRELEASE-620) NPE on a range dependency
[
https://jira.codehaus.org/browse/MRELEASE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296603#comment-296603
]
Jiri Patera commented on MRELEASE-620:
--
Just to let you know. I tested the use-case with Maven 2.2.1 and
{{org.apache.maven.plugins:maven-release-plugin:2.2}} and the NPE still appears.
In addition I tested the issue with Maven 3.0.4 and
{{org.apache.maven.plugins:maven-release-plugin:2.2}}. The result is without
the exception. So this seems to be fixed in Maven 3.0.4.
{code}
$ mvn3 --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /opt/apache-maven-3
Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
Java home: /opt/java/jdk1.6.0_31/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.0.0-15-generic", arch: "amd64", family: "unix"
$ mvn3 org.apache.maven.plugins:maven-release-plugin:2.2:prepare -DdryRun=true
...
[INFO] Release preparation simulation complete.
[INFO]
[INFO] BUILD SUCCESS
{code}
> NPE on a range dependency
> -
>
> Key: MRELEASE-620
> URL: https://jira.codehaus.org/browse/MRELEASE-620
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
> Environment: maven 2.2.1
>Reporter: Michal Politowski
> Attachments: pom.xml
>
>
> The symptoms are similar to MRELEASE-318 but using the 2.1 version which
> should have it fixed.
> With the attached very minimal project
> {{mvn org.apache.maven.plugins:maven-release-plugin:2.1:prepare
> -DdryRun=true}}
> results in
> {noformat}
> java.lang.NullPointerException: version was null for org.mortbay.jetty:jetty
> at
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
> at
> org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
> at
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
> at
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
> at
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
> at
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
> at
> org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.simulate(CheckDependencySnapshotsPhase.java:290)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
> 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.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> 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:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainW
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail
[
https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Patera updated MNG-4831:
-
Attachment: maven-bug-simulation-MNG-4831.zip
Attached a simple example which clearly simulates this issue
([^maven-bug-simulation-MNG-4831.zip]). One can easily play with it to see the
results (just call {{mvn clean verify}} on the multiproject).
B and C both depend on A. In the {{result}} artifact there are two assembly
descriptors to create two ZIP files with the dependencies. If everything
worked, the expected output would be two ZIP files. One with B and A {{jar}}
files. The other with C and A {{jar}} files. However, the result is one ZIP
file with B and A {{jar}} files and the other ZIP file with C {{jar}} only.
As [~rkrell] states, one workaround is to change the order of artifacts (usable
only for one {{maven-assembly-plugin}} configuration in the {{result}}
artifact). The other, perhaps, to create two separate artifacts (one for each
{{maven-assembly-plugin}} configuration) and make sure no filtering on the
dependency tree happens. If necessary, one can play with the [Dependency
Mediation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
to achieve their goals... None of these workarounds seems nice.
> artifact.getDependencyTrail() doesn't include full information; causes
> problems filtering artifacts by transitive dependency trail
> --
>
> Key: MNG-4831
> URL: https://jira.codehaus.org/browse/MNG-4831
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.2.1, 3.0-beta-3
>Reporter: John Casey
> Attachments: maven-bug-simulation-MNG-4831.zip
>
>
> Artifact.getDependencyTrail() is a List, not a graph. This means the artifact
> doesn't include information about every artifact that depends on that
> artifact.
> In cases where the project's artifacts are filtered using the dependency
> trail, it can become impossible to capture the full dependency closure for an
> included artifact if that artifact depends on something that an excluded
> artifact also depends on.
> For a concrete example / test case of this, see MASSEMBLY-504.
> In this example, A and B both depend on C. However, the dependencySet
> _excludes_ B from the assembly. By luck of the draw, profile dependencies are
> appended to the project's other dependencies, and B is in the dependencyTrail
> of C, not A (both are valid to be there). Since transitive filtering is
> enabled, C is _excluded_ from the assembly along with B, and the classpath
> for A is not fully represented.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
