Weird. I'm now seeing that this Gradle script will fail or succeed
depending on what directory I execute it from. If I execute it from the
original project directory where I first saw this problem, it fails. If I
execute it from a different directory that just holds this build script, it
succeeds. I don't see anything significant in the project that directory
that might make this happen. I'm currently comparing the verbose
classloading output from both tests to see if I can find any clues.
On Fri, Jan 23, 2015 at 6:58 AM, David Karr <davidmichaelkarr_at_gmail.com>
wrote:
> 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.
>>
>>
>>
>