[
https://issues.apache.org/jira/browse/SUREFIRE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635651#comment-15635651
]
Thomas Mortagne commented on SUREFIRE-1298:
-------------------------------------------
It is a problem for anything that assume the pom.xml means that the jar
contains common-io (which is what this file is supposed to mean). It's not
super blocker since it's only build and not runtime still it's not very nice to
get warning that I have some potential conflict in by classpath (and I would
prefer to hack to remove it be on your side than mine ;)). But maybe it should
actually be shade plugin job in the end.
Do you really need to embed commons-io ? Couldn't it be a standard Maven
dependency ?
> 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
>
> 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)
