[
https://issues.apache.org/jira/browse/SUREFIRE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639480#comment-15639480
]
Thomas Mortagne edited comment on SUREFIRE-1298 at 11/5/16 12:10 PM:
---------------------------------------------------------------------
bq. Is it a problem that we incluse commons pom.xml?
This is my direct issue. The fact that the jar contains a descriptor saying in
contains commons-io which is not true (since it's not the same packages).
bq. Is it a problem that we include but repackage all dependencies except for
commons-io? Please extract the *.jar file and see the packages.
I don't mind that you shade whatever you want (as long as the jar then does not
contain a pom saying it contains something for which you actually modified all
packages). I just find pretty weird to shade common-io instead of just
depending on it.
bq. Can you show me the real warning from classpath as you mentioned?
It won't really help you, it's nothing standard. I as said I have a tool (an
extension manger) looking at the classpath to knows what is already there (and
also checking if the classpath contains the same artifact in different versions
to warn about possible issues). And for that it look at Maven pom located in
jars since they are supposed to describe what the jar contains (plus some hacks
for jars not containing any pom.xml).
was (Author: tmortagne):
> Is it a problem that we incluse commons pom.xml?
This is my direct issue. The fact that the jar contains a descriptor saying in
contains commons-io which is not true (since it's not the same packages).
> Is it a problem that we include but repackage all dependencies except for
> commons-io? Please extract the *.jar file and see the packages.
I don't mind that you shade whatever you want (as long as the jar then does not
contain a pom saying it contains something for which you actually modified all
packages). I just find pretty weird to shade common-io instead of just
depending on it.
> Can you show me the real warning from classpath as you mentioned?
It won't really help you, it's nothing standard. I as said I have a tool (an
extension manger) looking at the classpath to knows what is already there (and
also checking if the classpath contains the same artifact in different versions
to warn about possible issues). And for that it look at Maven pom located in
jars since they are supposed to describe what the jar contains (plus some hacks
for jars not containing any pom.xml).
> surefire-junit4 contains commons-io 2.2 pom.xml
> -----------------------------------------------
>
> Key: SUREFIRE-1298
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1298
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
> Affects Versions: 2.19.1
> Reporter: Thomas Mortagne
> Assignee: Tibor Digana
>
> For some reason surefire-junit4 jar ends up with
> {{/META-INF/maven/commons-io/commons-io/pom.xml}} (and {{pom.properties}}).
> The issue is that I have some code scanning classloader jars to find out
> what's there and I end up with a conflict in all my unit tests between
> commons-io 2.9 in commons-io jar I'm depending on and commons-io 2.2 which is
> supposed to be in surefire-junit4 jar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
