Получите "Поставщик x не подтип" при использовании расширений JAXB

Question

Ранее я публиковал это, но я думаю, что лучше перефразировать проблему, так как я не получил никакого полезного ответа от этого или любого другого места, которое я пытался спросить об этом.

Я пытаюсь использовать несколько существующих расширений JAXB при создании классов из XJC. Эта обработка долгое время работала нормально в сборке Maven, используя "cxf-xjc-plugin". Я пытаюсь преобразовать эту сборку в Gradle, но обнаружил, что все другие стратегии, кроме сборки Maven, терпят неудачу с той же ошибкой, которая выглядит примерно так:

Вызывается: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Поставщик com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin не является подтипом com.sun.tools.xjc.Options.findServices(Options.java:957) в com.sun.tools.xjc.Options.getAllPlugins(Options.java:374) в com.sun.tools.xjc.Options.parseArgument(Options.java:688) в com.sun.tools.xjc.Options.parseArguments(Options.java:809) в com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474) в com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:7) в com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380) в com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103) в org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) в org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

Я могу продемонстрировать это с помощью одного простого скрипта сборки Gradle. Для компиляции не требуется никакого исходного кода или схем, ошибка возникает при настройке пути к классам.

Обратите внимание, что, хотя ошибка здесь ссылается на плагин "Element Wrapper", если я удаляю этот jar-файл из classpath, я получаю ту же ошибку, но вместо этого ссылаюсь на другое расширение JAXB, расширение "Fluent API". Насколько я знаю, я ссылаюсь на последние версии обоих этих расширений, а также на последние версии XJC и связанных jar-файлов.

Мой текущий простой тестовый скрипт Gradle выглядит так (я называю его "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

Я запускаю это с помощью "gradle -b testxjc.gradle build --stacktrace"

Я также смог продемонстрировать ту же ошибку, обходя задачу Ant и напрямую используя класс XJCFacade. Это требует наличия необходимых банок для справки. Вот мой текущий тестовый скрипт (замените точку с запятой на двоеточие в classpath, если вы тестируете это в 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

Я проверял это на Win7 и CentOS.

Обновить:

Теперь у меня есть ключ или два.

Во-первых, когда я сказал, что проверял это на Win7 и CentOS, я имел в виду сценарий оболочки. До этого момента я не запускал минимальный скрипт сборки Gradle на CentOS. Когда я запустил этот минимальный скрипт сборки Gradle на CentOS, он преуспел (что означает, что он пожаловался на отсутствующую схему). Помимо разных операционных систем у меня есть разные версии Gradle и Java на каждой коробке. Я нахожусь в процессе обмена этими версиями, чтобы увидеть, какие еще подсказки я могу найти.

Я также получил ответ на сообщение, которое я сделал в списке рассылки "jaxb-dev", где кто-то сказал, что он видел этот симптом, и они думают, что это может произойти, когда на пути к классам найдено несколько JAXB-файлов, и некоторые JAXB классы загружаются одним загрузчиком классов, а другие классы JAXB - другим.

Исходя из этого, я полагаю, что мне следует попробовать выполнить мой минимальный тест с подробной загрузкой классов и посмотреть, как они отличаются, но я не уверен, что смогу увидеть, что мне нужно, через весь шум, который будет производить.