I posted this one earlier, but I think it's best to rephrase the problem, as I don't have a useful answer from this or any other place. I tried to ask about it.
I am trying to use a couple of existing JAXB extensions when creating classes from XJC. This processing worked for a long time in the Maven assembly using the "cxf-xjc-plugin". I am trying to convert this assembly to Gradle, but I found that all other strategies besides the Maven assembly fail with the same error, something like this:
Called: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: provider com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin is not a subtype of at com.sun.tools.xjc.Options.findServices (Options. java: 957) at com.sun.tools.xjc.Options.getAllPlugins (Options.javahaps74) at com.sun.tools.xjc.Options.parseArgument (Options.java:688) at com.sun.tools.xjc .Options.parseArguments (Options.java:809) on com.sun.tools.xjc.XJC2Task._doXJC (XJC2Task.java:474) on com.sun.tools.xjc.XJC2Task.doXJC (XJC2Task.java:457) on com.sun.tools.xjc.XJC2Task.execute (XJC2Task.javahaps80) at com.sun.istack.tools.ProtectedTask.execute (ProtectedTask.java:103) at org.apache.tools.ant.UnknownElement.execute ( UnknownElement.java:292) on org.apache.tools.ant.dispatch.DispatchUtils.execute (DispatchUtils.java:106)
I can demonstrate this with a simple simple Gradle build script. Compilation does not require any source code or schemes; an error occurs when setting the class path.
Please note that although the error here refers to the "Element Wrapper" plugin, if I remove this jar from the class path, I get the same error, but instead refer to another JAXB extension, the "Fluent API" extension. As far as I know, I am referring to the latest versions of both of these extensions and the recent versions of XJC and their associated jars.
My current simple test case for the Gradle script is this (I call it "testxjc.gradle"):
apply plugin: 'java' apply plugin: 'maven' apply plugin: 'war' sourceCompatibility = 1.7 targetCompatibility = 1.7 repositories { maven { url "http://repo1.maven.org/maven2/" } } configurations { jaxb } dependencies { jaxb 'com.sun.xml.bind:jaxb-xjc:2.2.7' jaxb "com.github.jaxb-xew-plugin:jaxb-xew-plugin:1.4" jaxb "net.java.dev.jaxb2-commons:jaxb-fluent-api:2.1.8" } task processXSDs() << { URLClassLoader loader = GroovyObject.class.classLoader; configurations.jaxb.each { File file -> println file; loader.addURL(file.toURI().toURL()) } ant.taskdef(name: 'xjc', classname: 'com.sun.tools.xjc.XJCTask', classpath: configurations.jaxb.asPath) ant.xjc(destdir: 'tmp', package: "com.att.sunlight.service.domain.serviceCallResults", extension: true) { schema(dir: "src/main/resources/schema", includes: "serviceCallResults.xsd") arg(value: "-Xxew") arg(value: "-summary target/xew-summary.txt") arg(value: "-instantiate lazy") arg(value: "-Xfluent-api") } } compileJava.dependsOn processXSDs
I run this with gradle -b testxjc.gradle build --stacktrace "
I was also able to demonstrate the same error bypassing the Ant task and using the XJCFacade class directly. This requires the presence of the required cans for reference. Here is my current test script (change semicolons to colons in the classpath if you check this on Linux):
#! /bin/bash java -classpath "lib/commons-beanutils-1.7.0.jar;lib/commons-lang-2.2.jar;lib/commons-logging-1.1.1.jar;lib/istack-commons-runtime-2.16.jar;lib/jaxb2-basics-runtime-0.6.5.jar;lib/jaxb2-basics-tools-0.6.5.jar;lib/jaxb-api-2.2.7.jar;lib/jaxb-core-2.2.7.jar;lib/jaxb-fluent-api-2.1.8.jar;lib/jaxb-xew-plugin-1.4.jar;lib/jaxb-xjc-2.2.7.jar" com.sun.tools.xjc.XJCFacade -extension
I tested this on both Win7 and CentOS.
Update:
Now I have a key or two.
First, when I said that I tested this on both Win7 and CentOS, I had in mind the shell script. Until now, I have not run the minimal Gradle script construct on CentOS. When I ran this minimal Gradle build script on CentOS, it succeeded (which means it complained about the missing circuit). Besides different OSs, I have different versions of Gradle and Java on each box. I am in the process of exchanging these versions to find out what other keys they can find.
I also received a response to the message I did on the jaxb-dev mailing list where someone said that they saw this symptom and they think it can happen when several JAXB tanks are on the class path, and some JAXB classes are loaded by one class loader and other JAXB classes by another.
From this input, I suppose I should try to run my minimal test with a detailed loading of the classes and see how they differ, but I'm not sure I can see what I need for all the noise that will produce.