IntelliJ using old version of class; how to exclude?
When running a Java unit test straight from IntelliJ (rather than from maven), the test throws a NoSuchMethodError, because IntelliJ uses an older version of commons-io, and for the life of me I can't figure out why it's doing that.
My .m2/repository does contain older versions of commons-io, and if I delete them, building the project from maven downloads them again. As far as I can tell, this is caused by maven plugins that have dependencies to those older versions.
But those maven plugins shouldn't matter to IntelliJ. Either it should ignore them, or understand them well enough to ignore their dependencies when they conflict with my project's dependencies.
I've tried excluding them through Run/Debug Configuration → Modify options → Modify Classpath → Exclude, but the list of libraries I can exclude only contains the newer version of commons-io that IntelliJ should be using, but still doesn't.
How do I inject some sense into this contradictory behaviour?
请先登录再写评论。
Hello!
Thank you for reporting this!
Some of the Test Run Configuration rely on IDEA's Native Build System and not Maven, which may explain the inconsistency.
Would you be able to share a reproducer Project, so we can investigate and resolve this?
Also, consider using Dependency Analyzer to see which one of the Project's dependencies pulls in the outdated one, so you can update or override it.
According to both the dependency analyzer and `mvn dependency:tree`, there are a bunch of dependencies that require an older version: 2.11. But `mvn dependency:tree` says they're omitted because of the conflict. The dependency analyzer recognises the conflict. So then why are they still used, if every tool understands that they conflict with something more recent?
Some even older versions are used by a couple of maven plugins: resource, compile and surefire. I've tried overriding those, but they still got downloaded.
As mentioned above, this might be a case where IDEA's Build System resolves the dependencies in a way that's different to Maven's.
A reproducer Project would really help us to get to the bottom of this.
As a workaround, try enabling “Delegate IDE build/run actions to Maven” option.
Creating a reproducer project is not so easy, because this is a pretty complex project. There are several maven subprojects in it, and this particular one consists of several neo4j plugins that share a parent pom. And that's what seems to have caused this problem: maven is aware of the parent pom, but when IntelliJ uses JUnit to run the unit tests, the dependency override in the parent pom is ignored.
Adding the dependency for the correct version of commons-io to the subproject pom seems to solve the problem.
This is very much understandable!
Would you able to to share the
commons-ioversions and the specific test that was erroring out (or name of the method that was causing theNoSuchMethodErrorerror), so I can try and reproduce this on my end?