[MSHARED-396] Created manifest contains versions of test scope

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Not A Problem
• Component/s: maven-archiver
• Assignee: Unassigned
• Reporter: Ittai Zeidman
• Created: 07/Jan/15 00:42
• Updated: 30/Sep/17 10:53
• Resolved: 07/Jan/15 14:26

Description

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.

Issue Links

• is cloned by: MSHARED-659 CLONE - Created manifest contains versions of test scope