maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Murashenkov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MSHARED-659) CLONE - Created manifest contains versions of test scope
Date Sat, 30 Sep 2017 11:00:01 GMT

     [ 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)

Mime
View raw message