Hi davestein, could your problem be a duplicate of JENKINS-43512 ?

Another plugin is messing with the classpath of Jenkins and is loading org.apache.xerces.jaxp.DocumentBuilderFactoryImpl which is making the JVM XML API break.

No dependency to Xerces found in the jenkins clover plugin (https://gist.github.com/cyrille-leclerc/eea960faced7383ec1a1e849eca7b192).

davestein did you install the jenkins jacoco plugin on your master?

I searched for that in my installed plugins and didn't see anything (as I know there were plenty default installed). I know that when I do a freestyle project, maven is running those goals fine. Both my pipeline and freestyle exist to test a plugin I wrote, which reads some data off of clover. So everything works great in both situations, except when using the pipeline command listed above. I imagine if jacoco (or another plugin) were the issue, it would fail on freestyle as well.

Can you run the following script in the "Groovy console" of your master to understand which plugin provides this "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl" that is not accepted by the JVM parser?

String className = "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"

Class klass
try {
  klass = Class.forName(className)
} catch (Exception e) {
  println("Exception trying to load " + className + " from the system classloader, try the thread context classloader " + e)
  // contextClassLoader should not work but let's try it.
  klass = Class.forName(className, false, Thread.currentThread().getContextClassLoader())
}

java.security.CodeSource codeSource = klass.getProtectionDomain().getCodeSource()

if (codeSource == null) {
  println(klass.toString() + " -> source not found")
} else {
  println(klass.toString() + " -> " + codeSource.getLocation());
}

By Groovy Console? Did you mean the pipeline textarea? Didn't know you could do that but... something did happen.

 
[Pipeline] echo
Exception trying to load org.apache.xerces.jaxp.DocumentBuilderFactoryImpl from the system classloader, try the thread context classloader org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use staticMethod java.lang.Class forName java.lang.String
[Pipeline] End of Pipeline
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use staticMethod java.lang.Thread currentThread
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectStaticMethod(StaticWhitelist.java:189)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onStaticCall(SandboxInterceptor.java:160)
at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:184)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.java:188)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:95)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
at WorkflowScript.run(WorkflowScript:9)
at __cps.transform__(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixName(FunctionCallBlock.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122)
at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
 

Ahhh: 

class org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -> file:/var/jenkins_home/plugins/registry_reporter/WEB-INF/lib/xercesImpl-2.6.2.jar

The weird thing is that I think I had this issue in the past, if I had the Jenkins version go too high. But that was impacting Freestyle project at the time, whereas right now I am fine there but not pipeline.

davestein I have added an entry in the FAQ: Why do I see messages "javax.xml.parsers.FactoryConfigurationError: Provider for class javax.xml.parsers.DocumentBuilderFactory cannot be created".

davestein can you fix this plugin "registry_reporter" that does not seem to be a Jenkins Community plugin? The best fix would be to exclude the dependency on xerces. A workaround would be to bump the version of Xerces to the latest.

cleclerc do you have any idea why it would only fail in pipeline case rather than freestyle? I can make updates to the private plugin and see about fixing it, but am still curious about this difference.

Hm I realized something is really wonky here. Even when I don't run my custom plugin, this error is still happening. For sanity's sake, I did bump my plugins deps from xom 1.1 to 1.2.5, however the pipeline has same failure. Not sure how my plugin is impacting maven goals when the plugin step isn't even being called. xom is how xerces is being called, I don't explicitly require it.

>  Not sure how my plugin is impacting maven goals when the plugin step isn't even being called. xom is how xerces is being called, I don't explicitly require it.

The withMaven plugin parses the xml file generated by the maven-event-spy it has injected in the environment. If the XML parsing API of the Jenkins master is broken by a plugins that injects an outdated xerces version then withMaven will have errors.

> Not sure how my plugin is impacting maven goals when the plugin step isn't even being called. xom is how xerces is being called, I don't explicitly require it.

Can you exclude the xerces dependency of your "registry_reporter" plugin? The JVM comes with a xerxes implementation under a shadowed package "com.sun.org.apache.xerces"

.

davestein ping

Sorry, thought I replied to this. I am not explicitly requiring xerxes. It comes down through my dependency on xom package. Should I open a ticket with them and reference this one?

davestein I would recommend you to tweak your pom.xml to exclude or bump the outdated dependencies. I would prefer to exclude:

• either exclude the transitive dependency brought by "xom:xom": https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html#How_to_use_dependency_exclusions

<dependency>
    <groupId>xom</groupId>
    <artifactId>xom</artifactId>
    <version>1.2.5</version>
    <exclusions>
        <exclusion>
            <groupId>xml-apis</groupId>
            <artifactId>xml-apis</artifactId>
        </exclusion>
        <exclusion>
            <groupId>xerces</groupId>
            <artifactId>xercesImpl</artifactId>
        </exclusion>
        <exclusion>
            <groupId>xalan</groupId>
            <artifactId>xalan</artifactId>
        </exclusion>
    </exclusions>
</dependency>

• or bump xalan, xerces and xml-apis using Maven <dependencyManagement> in your pom.xml https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification#Dependency_Management

Reference: http://search.maven.org/remotecontent?filepath=xom/xom/1.2.5/xom-1.2.5.pom

Close as "not a defect" as the problem is not in the pipeline-maven-plugin but is in the other plugin that pulls an invalid version of XML libs and in jenkins-core that let plugins pollute/corrupt the entire JVM