Ok, thanks for the reply. I now have at least a minimal test case, and I've
even found a situation where the test succeeds.
I was able to build a minimal Gradle build script, and nothing else needs
to be manually installed (except for Java and Gradle) to run the test. This
test still fails on my Win7 box, but I found that it works on my CentOS
VM. I just compared the environments, and right now my Win7 box has Gradle
2.2.1 and the CentOS box only 2.1. Also, the CentOS box is running JDK 1.7
and the Win7 box 1.8. I'm going to do some swapping of those versions and
see what other variations provide a clue. I could also run either test
with verbose class loading, but I'm not sure what I'd look for in that
noise.
In any case, here's my minimal Gradle test script (not that the test
succeeds if it just complains about a missing schema):
-----------------------------
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'
sourceCompatibility = 1.7
targetCompatibility = 1.7
repositories {
mavenCentral()
}
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
-------------------------
On Fri, Jan 23, 2015 at 3:23 AM, Marcel Valovy <marcel.valovy_at_oracle.com>
wrote:
> Hi David,
>
> one of our teams has experienced the same problem with
> BeanValidationPlugin (part of EclipseLink). We are still analyzing the
> problem. I suspect that it is caused by having *multiple* different JAXB
> jars on classpath and having Context CL load one of the jars and having an
> APP CL load the plugin. When I get the info I need about the jars they use
> I will create a test case for this.
>
> Should you get any more information on this issue, I would greatly
> appreciate if you shared it with me/the group. I will share my results with
> you/the group too, after I get the required info.
>
> BR,
> Marcel
>
>
>
> On 21/01/15 17:12, David Karr wrote:
>
> This is not a proper subject for a "dev" list, but I've queried every
> other reasonable resource, with no result.
>
> I have a small app using CXF, JAX-RS, JAXB, along with two JAXB
> extensions, and Maven.
>
> I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and
> "Fluent API" JAXB extensions, to generate a set of Java classes from a set
> of schemas. This works fine.
>
> I'm attempting to convert this build from Maven to Gradle. The key part
> is XJC and these JAXB extensions. Ever single way I've tried to run XJC
> fails with the following exception (the referenced classname varies
> depending on whether I leave in both JAXB extensions or remove one from my
> classpath):
>
> Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin:
> Provider com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin not a subtype
> at com.sun.tools.xjc.Options.findServices(Options.java:957)
> at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
> at com.sun.tools.xjc.Options.parseArgument(Options.java:688)
> at com.sun.tools.xjc.Options.parseArguments(Options.java:809)
> at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474)
> at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
> at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
> at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>
> I've tried using the Ant XJC task from Gradle. I've tried it from an Ant
> "build.xml". I tried a Bash script directly calling the XJCFacade class.
> They all get the same result. I have the 2.2.7 version of the xjc, impl,
> and api jaxb jars in my classpath, along with the extension jars and other
> dependencies of those jars.
>
> I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they
> think this only works with the cxf maven plugin), stackoverflow, and the
> issues page for the ElementWrapper plugin. The only response of any
> substance I got was indirectly from Martin Gainty, from my ant-user
> posting, where he talked a bit about how the "ServiceLoader" framework
> works. He didn't really provide a solution, but he implied that "Maven
> solves the issue by inheriting System CL at CLI before tacking on
> maven-core and any consequent plugins". I've tried some classpath ordering
> changes along those lines, but that doesn't help.
>
> Any useful information or leads would be appreciated.
>
>
>