Compatibility with Jaxb xjc v3.0.0

[herveDarritchon]

Hi,

I have a kotlin ktor project that generates code from xsd using jaxb xjc. I have a few plugin such as xew. I have upgraded xjc today to version 3.0.0.

And after the upgrade, I have an issue in the plugin xew (please find bellow the stacktrace).
Obviously if I downgrade back to xjc 2.3.3, there is no issue during the build.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateCatalogSources'.
> 'void com.sun.tools.xjc.model.CElementPropertyInfo.<init>(java.lang.String, com.sun.tools.xjc.model.CElementPropertyInfo$CollectionMode, com.sun.xml.bind.v2.model.core.ID, javax.activation.MimeType, com.sun.xml.xsom.XSComponent, com.sun.tools.xjc.model.CCustomizations, org.xml.sax.Locator, boolean)'

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':generateCatalogSources'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:200)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:263)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:198)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:179)
        at ...
Caused by: java.lang.NoSuchMethodError: 'void com.sun.tools.xjc.model.CElementPropertyInfo.<init>(java.lang.String, com.sun.tools.xjc.model.CElementPropertyInfo$CollectionMode, com.sun.xml.bind.v2.model.core.ID, javax.activation.MimeType, com.sun.xml.xsom.XSComponent, com.sun.tools.xjc.model.CCustomizations, org.xml.sax.Locator, boolean)'
        at com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin.runInternal(XmlElementWrapperPlugin.java:451)
        at com.sun.tools.xjc.addon.xew.config.AbstractConfigurablePlugin.run(AbstractConfigurablePlugin.java:263)
        at com.sun.tools.xjc.model.Model.generateCode(Model.java:262)
        at com.sun.tools.xjc.Driver.run(Driver.java:354)
        at com.sun.tools.xjc.Driver.run(Driver.java:191)
        at Build_gradle$generateCatalogSourcesFunction$1.execute(build.gradle.kts:326)
...

Do you plan to upgrade the plugin to support xjc 3.0.0 ?

This is an extract of my build.gradle.kts

fun generateCatalogSourcesFunction(
    task: Task,
    catalog: CatalogType,
    generateNullableAnnotations: Boolean = true
) {
    task.description = "Generates Catalog sources from xsd."

    val packageName = catalog.toPackage()
    val inputDir = "$projectDir/src/main/resources/catalog/${catalog.toXsdFileName()}"
    val outputDir = "$buildDir/generated-sources/models/catalog/"

    task.inputs.file(inputDir)
    task.outputs.dir(outputDir)

    val args = listOfNotNull(
        "-d", outputDir,
        "-p", packageName,
        "-encoding", "UTF-8",
        "-no-header",
        "-Xxew",
        if (generateNullableAnnotations) "-XNullable" else null, // respecter l'ordre d'abord nullable puis toString
        "-XToStringHashCodeEquals", // laisser comme ça le temps que l'issue soit corrigée.
        inputDir
    )

    task.doLast {
        Driver.run(args.toTypedArray(), System.out, System.out)
    }
}

[dmak]

There have been few reports recently concerning the need to upgrade to xjc 3.0. Honestly, I have currently no time for that, so no promises at the moment.

[herveDarritchon]

There have been few reports recently concerning the need to upgrade to xjc 3.0. Honestly, I have currently no time for that, so no promises at the moment.

I understand ... I don't know if it is a complex stuff to do or just cumbersome work ;) I'd like to help to I think a need a help to bootstrap me to the project. If a new comer to the project can do it, I can be the guy but I think I need a bit of help from you ;)

[thetric]

Hi there, in https://github.com/thetric/jaxb-xew-plugin I have migrated this plugin to Jakarta EE. This are the major changes:

• feat: Upgraded to Jakarta XML Binding 3.0
• build: update to 'net.mcbluna.jaxb3_commons:jaxb3-basics-tools' which supports Jakarta XML Bindings 3 removed org.jvnet.jaxb2_commons:jaxb2-basics-tools because there are not official Jakarta EE compatible versions. I had found net.mcbluna.jaxb3_commons:jaxb3-basics-tools (Source: https://github.com/McBluna/jaxb3-basics) which supports JAXB 3. But this dependency is not published to Maven Central, just on a self hosted public Maven repository. I'm not sure how long the project and the server will be available
• build: increased minimum the minimum Java version to Java 8
• build: Migrated the build system to Gradle
• ci: migrated CI to GitHub actions
• test: migrated to JUnit 5 and XMLAssert 2

I had to replace org.jvnet.jaxb2_commons:jaxb2-basics-tools to net.mcbluna.jaxb3_commons:jaxb3-basics-tools (Source: https://github.com/McBluna/jaxb3-basics) which supports JAXB 3. This dependency is not published to Maven Central, just on a self hosted public Maven repository. I'm not sure how long the project and the server will be available. Either you could fork it into this group and publish it to Maven Central. Or one could replace the dependencies on it.

For my personal preference I've migrated from Maven to Gradle (I guess I could change it back).

[dmak]

Cool. I really appreciate what you do within this ticket! I hope to find a minute and merge it to master.

[bertramn]

Hi @thetric, in response to your use of mcbluna fork of the JAXB basics tooling, can you please only use libraries published to Maven Central? Personal repositories are not assessed for vulnerabilities and many organisations have blocking security rules to protect their supply chain hence making this plugin unusable.

[thetric]

Yes, I understand your concern. The problem is that I was not able to find any other version of org.jvnet.jaxb2_commons:jaxb2-basics-tools that is compatible with Jakarta EE. I see three solutions to this issue:

• Remove the dependency. This eliminates the risk completely.
• Fork the original source code into this project and make it compatible with Jakarta EE, the publish it to Maven Central.
• Search for official Jakarta EE compatible versions. As I already mentioned I was not successful 😕

What option do you prefer? Or do you see an alternative way to solve this problem?

[bertramn]

@thetric we could ship in and help Aleksei, the author of the JAXB Commons libraries to make them work with JAXB 3. There are a number of PRs and issues that people have clocked up over there already. Forking snippets and then not properly releasing them through a well known channel is not going to help anyone that already uses this plugin nor the poor chaps that start out fresh and fall into the many potholes of JAXB.

highsource/jaxb2-basics#118
highsource/jaxb-tools#199

Edit: consider what happens when someone tries to use this plugin with maven-jaxb2-plugin and now you have 2 separate JARs in the maven plugin classpath that both have the same package names but one is wired to use Jakarta and the other one the old Sun APIs.

[thetric]

To me it didn't looked like there was a new release of any of these libraries planned. Both pull requests have been merged over a year ago without resulting in new releases. Their latest releases are 3 years old. Thus I had chosen to refactored to remove the dependency on jaxb2-basics:

• directly calling the JAXB API instead of using helper methods that are one liners.
• inline two small methods from jaxb2-basics's AbstractPlugin and directly extending from the JAXB class Plugin

I am unsure on how we can help the maintainers to cut a new release, the necessary changes to ensure compatibility with Jakarta seem to have already landed. So, how do you suggest to support them?

[dmak]

I think we can break the dependency on jaxb2-basics and take over the necessary code. Once jaxb2-basics is released, we can refactor the code to use it...

[thetric]

Edit: consider what happens when someone tries to use this plugin with maven-jaxb2-plugin and now you have 2 separate JARs in the maven plugin classpath that both have the same package names but one is wired to use Jakarta and the other one the old Sun APIs.

I guess this is okay because maven-jaxb2-plugin is not actively maintained. The last commit on master was 2.5 years ago.
There are other Maven plugins (e.g. https://github.com/mojohaus/jaxb2-maven-plugin) that do support Jakarta 3.

Forking snippets and then not properly releasing them through a well known channel is not going to help anyone that already uses this plugin [...].

I have volunteered for this change because we are using this plugin with other tooling at work. This would enable us to finally migrate to Java 17.

I think we can break the dependency on jaxb2-basics and take over the necessary code. Once jaxb2-basics is released, we can refactor the code to use it...

@dmak Would you still like to review my PR?

[herveDarritchon]

any news about this issue ?

[pieter-v]

@dmak any chance to get this fixed and released by commiting #69

[plebcity]

When will this be merged? @thetric Can you release this version with jaxb 3.0 support?

[dmak]

Let's push this PR to the end: merge PR, make a release and push it to Maven.
@thetric I am a bit concerning with one major thing: why you have chosen Jakarta JAXB implementation in favor of Sun implementation (com.sun.xml.bind Maven group)? I am not familiar how Jakarta is different, but it seems to be an "extension" over Sun JAXB implementation?
Also I will try switching to codes.rafael.jaxb2_commons which is supposed to work with JAXB 2.3.0 and higher.
The rest of the changes (versions) are great. What about file src/test/generated_resources/.editorconfig? Was it added by mistake?

[plebcity]

@dmak Jakarta took over the development of the xml libraries that were originally developed by Sun. With that comes a new group name and the jaxb-impl has been renamed to jaxb-runtime. Jakarta is currently on JAXB 4.0 right now and many major frameworks have migrated their code base to Jakarta. Wildfly by Jboss and Spring Boot for example.

If it is possible then please upgrade this maven plugin to JAXB 4.0 but 3.0 is fine for now.

[dmak]

Thanks for information, @plebcity. I still have a mess why JAXB runtime is under GlassFish umbrella.
@thetric Almost all your suggested changes are in my branch jakarta-3, except few minor things like booleans boxing/unboxing. There are some code formatting differences, which if you like, we can align. Are you using Eclipse?

[plebcity]

Thanks for information, @plebcity. I still have a mess why JAXB runtime is under GlassFish umbrella.

My bad, the jaxb-impl also has a 4.0.1 version. So you could either use the Sun jaxb-impl or Glassfish jaxb-runtime. According to this answer there is a slight difference in packaging. https://stackoverflow.com/a/72151763/3487046

[thetric]

There are some code formatting differences, which if you like, we can align. Are you using Eclipse?

Nope, I'm using IntelliJ. But I'm totally fine with your branch

[dmak]

OK gents, then I merge my branch to master, please don't pull master as probably I would need to force push to it a couple of times if release fails (quite a time had passed since I run it last time). Also I will try to setup CI via GitHub actions (just a trivial build).

[dmak]

New and shiny v2.0 of Xew plugin has been uploaded to Nexus. Happy testing!
And many thanks for all of you for your contribution! We had a great start of 2023.
P.S. I have noticed there is another release 2.0.0 made by @raphw based on JAXB 4.0.1, so there could be some confusion. As far as I can see, it automatically means dropping Java 8 support and switching to Java 11.

[laurentschoelens]

Edit: consider what happens when someone tries to use this plugin with maven-jaxb2-plugin and now you have 2 separate JARs in the maven plugin classpath that both have the same package names but one is wired to use Jakarta and the other one the old Sun APIs.

I guess this is okay because maven-jaxb2-plugin is not actively maintained. The last commit on master was 2.5 years ago. There are other Maven plugins (e.g. https://github.com/mojohaus/jaxb2-maven-plugin) that do support Jakarta 3.

Forking snippets and then not properly releasing them through a well known channel is not going to help anyone that already uses this plugin [...].

I have volunteered for this change because we are using this plugin with other tooling at work. This would enable us to finally migrate to Java 17.

I think we can break the dependency on jaxb2-basics and take over the necessary code. Once jaxb2-basics is released, we can refactor the code to use it...

@dmak Would you still like to review my PR?

Hi there (@dmak / @thetric),
Just found this helpful plugin and wanted to give you some news about highsource's project
Alexei's unfortunately passed away in January of 2021.
His repo has been taken back by another maintainer highsource/jaxb-tools#206
We are currently working on jakarta version of maven-jaxb2-plugin with jaxb2-basics ans jaxb-annotate, but before we need to merge these repos since they depend on each others to build.
Once done, we'll be able to provide a jakarta jdk8 jaxb3 compatible version of these components and then a jakarta jdk11 jaxb4.

I'll try to ping you when done

[dmak]

@laurentschoelens Thanks for update. There is no direct dependency on jaxb-tools in this project, but it creates issues with other plugins with use jaxb-tools if they are mixed with jaxb-xew-plugin . Nevertheless I would be happy to test integration with other plugins, once they are released with JAXB 3.x or later.
Sorry to hear sad news about Alexei 😢

[laurentschoelens]

Hi @dmak

We finally get v3 and v4 jaxb-tools based on jaxb3 and jaxb4.
V3 and V4 had no breaking changes.
I invite you to check migration guide.

Regards
Laurent