Maven Dependency Conflict: org.w3c.dom.ElementTraversal Maven Dependency Conflict: org.w3c.dom.ElementTraversal spring spring

Maven Dependency Conflict: org.w3c.dom.ElementTraversal


In my case the problem was fixed by changing the version of xml-apis from 1.3.04 to 1.4.01


It looks as though you don't have the xml-apis dependency specified in your child pom. The <dependencyManagement> section does not cause dependencies to be included, it just supplies configuration which can be inherited. It looks like some of the dependencies in your child pom are pulling in xml-apis transitively, but for some weird Maven quirk, the one that's winning (version 1.4.01) is in test scope; presumably it is in test scope in whichever dependency specifies it. Transitive dependencies in test scope in the pom that specifies them will not be pulled in by your project's dependencies that are in test scope - that's quite a tricky sentence to parse, but there's a good explanation of Dependency Scope which might make things clearer.

Essentially what I'm looking at is your dependency-tree that shows one included version of xml-apis, as can be seen in this edited version of your output:

org.xssfinder:xssfinder-test:war:1.0-SNAPSHOT+- org.xssfinder:xssfinder-executor-java:jar:1.0-SNAPSHOT:compile   +- org.reflections:reflections-maven:jar:0.9.8:compile      +- org.reflections:reflections:jar:0.9.8:compile         +- com.google.guava:guava:jar:14.0:compile         +- javassist:javassist:jar:3.12.1.GA:compile         \- dom4j:dom4j:jar:1.6.1:compile            \- xml-apis:xml-apis:jar:1.4.01:test

I'm not completely sure why that's coming through as test scope, but I'm guessing that's the problem. I'd recommend adding the xml-apis dependency explicitly into your child pom, and seeing if it affects the dependency-tree - you're trying to avoid pulling it in as a transitive dependency, to see if you can resolve the problem.


I have resolved this in the end, but fairly unsatisfactorily. The fix was to mark xml-apis as in the runtime scope in the dependencyManagement section of the parent pom.

I'm not entirely clear on why this works (and in particular, why it works whereas specifying the dependency as in the compile scope does not work). If anyone thinks they can adequately explain that, I'd like to know.