I built sonar-xml from source by its latest tag
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
Are those classes under
javax.xml added by maven plugin
sonar-packaging-maven-plugin? why not use those classes from jdk?
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?