Ittai Zeidman created MSHARED-396:
-------------------------------------
Summary: Created manifest contains versions of test scope
Key: MSHARED-396
URL: https://jira.codehaus.org/browse/MSHARED-396
Project: Maven Shared Components
Issue Type: Bug
Components: maven-archiver
Reporter: Ittai Zeidman
Attachments: dependency-bug.zip
Hi,
I'm not 100% sure this issue belongs here and not in maven-project itself but
seeing as this is where I'm having the issue I thought I'd start here.
When building the classpath for a manifest the chosen version of an artifact is
based on all scopes and not only on compile/runtime.
This is an issue in the following layout:
Main-Artifact
test-dependency-which-directly-depends-on-old-javassist (test)
javassist: 3.15.0-GA
compile-dependency-which-transitively-depends-on-new-javassist (compile)
dependency-which-directly-depends-on-new-javassist
javassist: 3.16.1-GA
I'm getting javassist 3.15.0-GA in my classpath and getting a method not found
during runtime when using methods from the newer version.
I would expect maven to do the "nearest path" resolution on the subset of
artifacts which actually compete on the same classpath (i.e. runtime).
I know that maven-archiver is just using project.getRuntimeClasspathElements
which uses project.getArtifacts which returns the old version but I think
maven-archiver can decide to use a different resolution mechanism.
I say this because we also use the maven-assembly-plugin to copy the
dependencies and that does the correct, IMO, resolution.
I've attached a multi-module project which demonstrates this.
Simply run jar:jar in the main-artifact module and take a look in the manifest
file of that jar [I'm using archiver via jar-plugin since that is my use-case].
I'm really willing to try and submit a patch or even just test-cases but I
wanted to know what you think of the issue first.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
