JaxB 2.3 support?

[dbirch-cognitoiq]

I'm finding your plugin great to use and it does most of what I need, however, I have a jaxb plugin which requires JaxB 2.3+ in order to give me the features I need.

How hard would it be to update the version of jaxb this plugin depends on to 2.3 or greater?

Pretty new to jaxb, happy to try and fork and make the changes myself if it's not too difficult and there's a good reason for you sticking to 2.2?

[tkrullmann]

Hi,

it might be enough to add the JAXB 2.3 dependencies to your buildscript classpath, e.g.

buildscript {
    dependencies {
        classpath 'javax.xml.bind:jaxb-api:2.3.1'
        classpath 'com.sun.xml.bind:jaxb-impl:2.3.1'
        classpath 'com.sun.xml.bind:jaxb-xjc:2.3.1'
    }
}

so they would override the transitive dependencies from the plugin.

Updating the default version of the plugin has to be handled more carefully -- unlike the JAXB Maven plugin this does not spawn an external process for XJC but runs it directly inside the Gradle process. So the plugin is actually compiled against a specific version of JAXB, and updating this version might be a breaking change.

I could imagine having the version configurable like

xjc {
    jaxbVersion = '2.3.1'
}

[dbirch-cognitoiq]

I shall give that a try tomorrow and let you know how I get on, thanks :)

Time to roll back from using the plugins dsl and back to the buildscript config.

[dbirch-cognitoiq]

Hmm, tried that, but seems to now be having issues parsing my plugin activation arguments:

com.sun.tools.xjc.BadCommandLineException: unrecognized parameter -Xfluent-builder

I wouldn't expect a change to the classpath options between 2.2 and 2.3, which looking at the options class from the stacktrace would seem to be the obvious smoking gun. I guess I will need to dig more. Any advice would be greatly appreciated :)

[dbirch-cognitoiq]

Bit more of an update on this one - the issue seems to be an odd one. For some reason they have changed the getAllPlugins() method in com.sun.tools.xjc.Options in 2.3.x so that instead of using the user classpath defined in the options file when parsing plugin activations, it only uses Plugin.class.

Thus none of the plugins defined on the classpath are loaded and can be specified.

Managed to fix this by calling:

Thread.currentThread().setContextClassLoader(options.getUserClassLoader(Thread.currentThread().getContextClassLoader()))

Within XjcGenerate after setting the options.classpaths from pluginClasspath.

I'm tempted to add the configurable jaxb version as you suggest and put in a pull request with this change as it now seems to work with 2.3.1, but have absolutely no idea how I go about implementing this and getting it to actually control the dependency version which is loaded. Not done much work with writing gradle plugins before.

If I put in a pull request with what I have, can you help me to add in this configurable jaxb version property?

[tkrullmann]

XJC/JAXB version switch is now supported in the new plugin version 2.0. It uses Gradle worker API with classpath isolation, so using different XJC versions with the same plugin version is now possible.