[jira] [Updated] (MSHARED-659) CLONE - Created manifest contains versions of test scope

["Dmitry Murashenkov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MSHARED-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Murashenkov updated MSHARED-659:
---------------------------------------
    Description: 
I'd like to reopen the issue MSHARED-396.

So the case is extremely simple:

1. Maven module creates executable jar adding classpath to manifest.
2. Then assembly plugin packs executable jar and it's dependencies into archive/
3. Then we unpack app and launch it with java -jar myexecutable.jar. All dependencies are places in same folder and referenced by manifest classpath.

Now suppose we had one library of version 1.0 in runtime scope and 1.5 in test scope. Current behavior is that manifest classpath will have version 1.5 set, but assembly plugin will pack 1.0 cause we only take runtime dependencies. And this may result in ClassNotFoundException in production.

Perhaps it has something to do with MSHARED-4?

  was:
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. 


> CLONE - Created manifest contains versions of test scope
> --------------------------------------------------------
>
>                 Key: MSHARED-659
>                 URL: https://issues.apache.org/jira/browse/MSHARED-659
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-archiver
>            Reporter: Dmitry Murashenkov
>         Attachments: dependency-bug.zip
>
>
> I'd like to reopen the issue MSHARED-396.
> So the case is extremely simple:
> 1. Maven module creates executable jar adding classpath to manifest.
> 2. Then assembly plugin packs executable jar and it's dependencies into archive/
> 3. Then we unpack app and launch it with java -jar myexecutable.jar. All dependencies are places in same folder and referenced by manifest classpath.
> Now suppose we had one library of version 1.0 in runtime scope and 1.5 in test scope. Current behavior is that manifest classpath will have version 1.5 set, but assembly plugin will pack 1.0 cause we only take runtime dependencies. And this may result in ClassNotFoundException in production.
> Perhaps it has something to do with MSHARED-4?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)