Remove simple-xml dependecy in favor of JAXB

[mackdk]

What does this PR change?

This PR drops the dependency on simple-xml in favor of standard JAXB.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

• DONE

Test coverage

• No tests: already covered

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[github-actions]

👋 Hello! Thanks for contributing to our project.
Acceptance tests will take some time (aprox. 1h), please be patient ☕
You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/7855/checks
Once tests finish, if they fail, you can check 👀 the cucumber report. See the link at the output of the action.
You can also check the artifacts section, which contains the logs at https://github.com/uyuni-project/uyuni/pull/7855/checks.

If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code.

Reference tests:

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary_parallel.yml?query=event%3Aschedule

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary.yml?query=event%3Aschedule

KNOWN ISSUES

Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience.

For more tips on troubleshooting, see the troubleshooting guide.

Happy hacking!
⚠️ You should not merge if acceptance tests fail to pass. ⚠️

[github-actions]

Suggested tests to cover this Pull Request

• min_deblike_openscap_audit
• srv_menu
• min_salt_openscap_audit
• min_rhlike_openscap_audit
• srv_task_status_engine
• srv_sync_products

[mcalmer]

standard JAXB? I read a lot that this was dropped in Java17 and you need to use external jar which might need "jakarta.xml.bind" namespace. Please check

[mcalmer]

Hmm, didn't I just read that this was deprecated again in Java 17 ?
Or is this an external jar?

[mackdk]

Yes, standard is the wrong word here, it was more in the sense of base, plain 🙂 .

But indeed, JAXB was part of Java EE which no longer exists, and now is part of jakarta so when we update the jar we will need to update the package names. I wanted to migrate away from simple-xml since it's a 10 years old unmaintened library. We can also investigate other frameworks, but jaxb is currently part of our dependencies so I didn't have to add add anything new:

        <dependency org="suse" name="jaxb-runtime" rev="2.3.1" />
        <dependency org="suse" name="jaxb-impl" rev="2.3.1" />

[mcalmer]

Let's hope the best that this provides everything what we need. This is the only path I found in the jar which I know :-)
glassfish-jaxb/jaxb-impl.jar

  35  Defl:N       37  -6% 2024-01-12 06:58 2499855a  META-INF/services/javax.xml.bind.JAXBContext

[admd]

More for an FYI: We decided to use StAX over JAXB but that's because we had big dataset here #7108. Here in this case, we should be fine with JAXB. Ideally, would have been nice to use the same library though.

[mackdk]

Ideally, would have been nice to use the same library though.

Indeed, that would require rewriting all the scap logic since StAX does not map XML to objects. It's totally doable, maybe even better, but requires changing how we process the results. Other drop in alternative might be Jackson but that would need an additional jar we currently don't have (jackson-dataformat-xml)

[admd]

Ideally, would have been nice to use the same library though.

Indeed, that would require rewriting all the scap logic since StAX does not map XML to objects. It's totally doable, maybe even better, but requires changing how we process the results. Other drop in alternative might be Jackson but that would need an additional jar we currently don't have (jackson-dataformat-xml)

@mackdk For now, I would say we are fine but I would appreciate if you could create a card to revisit this so we could align it depending on the effort required.

@rjmateus any thoughts on this one?

[rjmateus]

I agree with Abid, I think we are fine on moving forward with this one, and creating a card to revisit in the future.
It's great to get rid of simple-xml. Stax is a different implementation, but is the best approach for large data sets, like in the CVE case.
For small datasets jaxb is a much more convenient library, and simpler to use.

[cbosdo]

I'm not confident in giving an ACK on this one. I hope it doesn't harm the OVAL parsing work...