I built sonar-xml from source by its latest tag 2.7.0.3820 (mvn clean package), I found that the final jar sonar-xml-plugin-2.7.0-SNAPSHOT.jar contains classes for package javax.xml. Even more, I decompiled javax.xml.xpath.XPathFactoryFinder.class, and the method _newFacotry will look for class org.apache.xpath.jaxp.XPathFactoryImpl as a last try, which is different from jdk’s behavior above java8, in jdk _newFactory will return com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl.
Are those classes under javax.xml added by maven plugin sonar-packaging-maven-plugin? why not use those classes from jdk?
Update:
I mimic this behavior in a test project, the final jar built by jdk8 contains javax.xml.xpath.XPathFactoryFinder.class which will return org.apache.xpath.jaxp.XPathFactoryImpl. You can run this jar with java -Djaxp.debug app.jar and the output is:
JAXP: using thread context class loader (sun.misc.Launcher$AppClassLoader@33909752) for search
JAXP: Looking up system property 'javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom'
JAXP: The property is undefined.
JAXP: found null in $java.home/jaxp.properties
JAXP: attempting to use the platform default W3C DOM XPath lib
JAXP: factory 'com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl' was found for http://java.sun.com/jaxp/xpath/dom
Hello World!
It seems that adding classes that conflict with jdk have no influence. So why add them in the first place?