The other minimal test I have is the following shell script, which directly
runs XJCFacade. This fails on both Win7 and CentOS (remove the cygpath
reference if you don't use cygwin):
------------------------
#! /bin/bash
basedir=$(cygpath -m $HOME/work/xjctest)
cp="\
$basedir/lib/jaxb-core-2.2.7.jar;\
$basedir/lib/jaxb-xjc-2.2.7.jar;\
$basedir/lib/jaxb-fluent-api-2.1.8.jar;\
$basedir/lib/jaxb-xew-plugin-1.4.jar;\
"
#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
java -classpath "$cp" com.sun.tools.xjc.XJCFacade -extension
---------------------
On Fri, Jan 23, 2015 at 9:00 AM, David Karr <davidmichaelkarr_at_gmail.com>
wrote:
> 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.
>>>
>>>
>>>
>>
>