DSS-2774 use Jakarta xml instead of Javax xml

[plebcity]

The entire repo has been migrated to JAXB 3.0 using Jakarta XML libraries instead of Javax XML libraries.

I've added a new module called jaxb-xew-plugin which is based on this plugin https://github.com/dmak/jaxb-xew-plugin. This plugin removes the wrapper classes around Collections in the generated code. As of writing this the plugin hasn't been updated to Jakarta but there is an open PR (dmak/jaxb-xew-plugin#69) of which I copied the code and created the module in DSS. This module can be removed and replaced by the new version of this plugin when the PR has been merged.

As a sidenote, I wasn't able to run all the tests because of some Keystore issues that I wasn't able to solve. So please run all tests before merging to make sure I fixed everything properly.

I hope this PR can be merged before the release of 5.12 as we are currently stuck on Spring Boot 2.7 because DSS hasn't migrated to JAXB 3.0 and Jakarta 3.0+ yet.

[bsanchezb]

Hi @plebcity ,

Thank you for this PR. It seems like jaxb-xew-plugin is to be updated soon, so I prefer to wait for the update, instead of embedding a complete copy of the project.

I see that the version of org.apache.santuario.xmlsec was not updated. Don't you experience any issues with XAdES module?
Will DSS also work after changes with the old (javax) versions of Spring/SpringBoot? We will need to ensure everything is compatible before making such big changes.

Best regards,
Aleksandr.

Edit: missed your sentence about unit tests. Ok, to be executed after the merge.

[plebcity]

Hi @plebcity ,

Thank you for this PR. It seems like jaxb-xew-plugin is to be updated soon, so I prefer to wait for the update, instead of embedding a complete copy of the project.

I see that the version of org.apache.santuario.xmlsec was not updated. Don't you experience any issues with XAdES module? Will DSS also work after changes with the old (javax) versions of Spring/SpringBoot? We will need to ensure everything is compatible before making such big changes.

Best regards, Aleksandr.

Edit: missed your sentence about unit tests. Ok, to be executed after the merge.

I've updated xmlsec to 3.0.1 and removed the jaxb-xew-plugin module because they released version 2.0 yesterday.
XAdES module had no real issues, I have 6 test failures in that module but all seem unrelated to the Jakarta upgrade. Errors seem to be related to expired certificates that can't be upgraded to Baseline-T.

I'm not sure yet about compatibility with older Spring versions. If you want to stay compatible you might want to consider having a separate branch and tags for the Jakarta version of DSS or release this as a new major version (6.x) and do all updates on 5.x and 6.x in the future. Many other projects released the Jakarta migration with a new major version but still support older majors.

[bsanchezb]

Hello,

I have added a new test branch jakarta-migration-wip containing a WIP code for migration to Jakarta.
We have decided that the next version of DSS 5.12 will stay on javax and for Jakarta more likely we will consider a switching to version 6.x. But the complete plan of new version release and support of older versions is to be discussed.

Currently I have a few issues with upgrading DSS to Jakarta:

• I would prefer to stay on org.jvnet.jaxb2.maven2:maven-jaxb2-plugin over org.codehaus.mojo:jaxb2-maven-plugin plugin for JAXB generation. The reason is not my personal opinion, but a difficulty with org.codehaus.mojo:jaxb2-maven-plugin to define the usage of generated JAXB classes with dependent modules (like using xmldsig JAXB classes within specs-xades module). I made some modifications in the code to avoid code duplication, but I do not like definition of a relative path to XSD schemas pointing to another module within local filesystem within catalog.cat file, and I was not able to find a clear way to define a reference to the dependency jar. With the old plugin it was possible to define a maven protocol directly pointing to a maven dependency and the code was clearer in general. According to GitHub of the plugin, the update to jakarta is planned soon.
• We need to wait for VeraPdf update for PDF/A support. That also seems to be planned in the near future.

I have executed all tests and did not find other implications so far. We need to wait for the aforementioned libraries updates and then we can proceed with the jakarta version release. Additionally, the dss-demonstration is also to be updated to the jakarta namespace (i.e. Spring-Boot 3 upgrade of the spring-webmvc application).

Best regards,
Aleksandr.

[vassik]

This seems to become a growing issue. Support for jakarta.* would be much appreciated. I addition it seems like you have adopted Jakarta EE 8 which is in practice Java EE edition under jakarta maven coordinates which makes it challenging with Jakarta EE 9+. As for org.jvnet.jaxb2.maven2:maven-jaxb2-plugin, there is https://github.com/patrodyne/hisrc-higherjaxb which is a fork of https://github.com/highsource/maven-jaxb2-plugin. Could be a solution while they are working on jakarta.* in org.jvnet.jaxb2.maven2:maven-jaxb2-plugin. It is a bit unclear when support is coming highsource/jaxb-tools#233

[zjedi]

This is a real issue, I think it should not be further delayed. @bsanchezb when can this be released?

[bsanchezb]

Hi @zjedi , listed in my previous message still applies unfortunately. We plan the release of DSS version with Jakarta until end of the year, but we are blocked because of the used dependencies.

[zjedi]

@bsanchezb Is there any chance you would agree to release "experimental" version 6, initially without PDF support? We don't need it and the jakarta issue seems to impact wider community. I tried your "wip" branch and the build is passing (with quick-init profile). I'll have to deal with this urgently, probably forking it myself.

Is it safe to use if we don't use the PDF modules? Are there any other issues you are aware of?

Regarding the maven plugin, what's the blocking issue? What would I need to fix in this direction?

Also the wip branch is a bit behind master, do you see fit to include master changes before forking?

[bsanchezb]

The biggest problem is not PDF/A, but the jaxb plugin required for XML parsing and generation. Without this plugin we cannot validate documents and produce reports. Based on their GitHub they are doing some work at this moment to release a Jakarta support, and we will wait for them.
The branch may work partially locally, but it currently has some issues we are not able to make a release with (see my previous messages).

Currently we work on the preparation of 5.12.1 version (contains some improvements for Mutual Recognition Agreement of Trust Services from third countries) and will target 5.13 after. Depending on upgrade of the dependencies, we may release version 6.x together with 5.13 (probably in the autumn), but it less likely going to happen earlier.

[zjedi]

Thanks for explanation @bsanchezb. Shouldn't some basic tests fail if the library is unable to validate/sign XMLs?

[bsanchezb]

You can try to run tests with "mvn clean install". "quick-init" profile skips unit tests.

[zjedi]

On the maven plugin side, this seems to be the release to watch https://github.com/highsource/maven-jaxb2-plugin/milestone/7

[raynay-r]

Do I understand it correctly that it is currently not possible to use EU DSS together with Java 17?

[bsanchezb]

@raynay-r , DSS 5.12.x can work with all Java versions from 8 to 19. However, DSS will not work with Jakarta namespaces in the main project, such as when using spring-boot 3.x.

[titro]

Any recommendations how to handle that issue? There is no Spring Boot 2.X support by the end of the year so time is running out....

[anitaan]

Any updates on this case? Facing the same issue that prevents us from upgrading from Spring 2.x to Spring Boot 3.

[rafallezankoAutenti]

Any updates on this case? Facing the same issue that prevents us from upgrading from Spring 2.x to Spring Boot 3.

Me too.

[plebcity]

@bsanchezb I've updated the MR to include the old plugin again (which has released a JAXB 4 version last week). Code generation seems to work fine now. I ran "quick-init" and everything seems to compile.

[bsanchezb]

Hi @plebcity ,

Thank you for the PR. I will take a look on it.

We plan to release a version DSS 6.0 with Jakarta migration just after we release version 5.13 (so the version 6.0 includes all new changes as well).

Best regards,
Aleksandr.

[plebcity]

How soon after 5.13 will you be able to release 6.0? As you can see there are lots of people waiting for this release

[pvandenbroucke]

Hello,

Release 6.0 should be done before the end of the year.

FYI, DSS 5.12.1 can already run with Spring Boot 3. You temporarily need to add JAXB based on javax in your dependencies.

We were waiting for the upgrade of the JAXB plugin.

Regards,

Pierrick

[anitaan]

HiThis is Good News.Thank you so much for Your effort.Kind regards Anita StøyleSendt fra min iPhone11. okt. 2023 kl. 07:46 skrev Pierrick Vandenbroucke ***@***.***>: Hello, Release 6.0 should be done before the end of the year. FYI, DSS 5.12.1 can already run with Spring Boot 3. You temporarily need to add JAXB based on javax in your dependencies. We were waiting for the upgrade of the JAXB plugin. Regards, Pierrick —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[pschyska]

Us, too 🙂

I have a gradle hack that rewrites the import statements using the shadow plugin:

// https://github.com/esig/dss/pull/165
// https://ec.europa.eu/digital-building-blocks/tracker/browse/DSS-2774
val testJar by
  tasks.registering(ShadowJar::class) {
    archiveClassifier = "tests"
    from(sourceSets.test.map { it.output })
    configurations = listOf(project.configurations.testRuntimeClasspath.get())
    relocate("javax.xml.bind", "jakarta.xml.bind")
    isZip64 = true
  }

tasks.test { classpath = testJar.get().outputs.files }

Note: this is for the test configuration, for the main sourceset's jar one should be able to configure the default shadowJar task.

Disclaimer: I can't verify that there aren't any API or runtime incompatibilities apart from the change package names. I'm in the "exploratory unit test" phase at this point.

[bsanchezb]

Dear all,

The develop branch has been migrated to Jakarta EE 9 / javax 3.
The release is planned for version 6.0, which will follow just after the release of DSS 5.13 version.

Feel free to test the branch.

P.S. The DSS version 5.x after 5.13 will be maintained only for critical hotfixes. No new features is planned for 5.x version.

Best regards,
Aleksandr

[pschyska]

@bsanchezb Thanks! Are you publishing SNAPSHOT builds somewhere? I tried "https://oss.sonatype.org/content/repositories/snapshots", at it's listed in your distributionManagement, but it only had a 5.11-SNAPSHOT.

[bsanchezb]

Hi @pschyska , snapshot builds are not published. You will need to check out the develop branch and build it yourself. Feel free to use "-P quick-init" profile to skip unit tests and javadoc creation.

[pschyska-2]

@bsanchezb Alright, thanks. I already built the branch locally successfully, and my unit test that hit the JAXB issue started to work. I'll just deploy that to our nexus for the time being.

[justinasdauksa]

@bsanchezb Are there any news on when you're planning to release version 6? Will it be available till end of year?

[bsanchezb]

@justinasdauksa The release of DSS 5.13 is planned until end of the year, then version 6.0 will follow as soon as possible. But no commitment about a date, because first we need to ensure the quality of the product.

[bsanchezb]

Dear all,

DSS 6.0 with Jakarta has been released: Release Notes

Merry Christmas and Happy New Year to all of you! Thank you for using our project 😃 Hope you enjoy it!

Best regards,
Aleksandr

Update: dss-demonstration 6.0 are released too.