Remove wrong dependencies from classpath

[mackdk]

What does this PR change?

This PR removes CheckStyle and JaCoCo from compilation and runtime classpath. This two jars contains bundled all their dependencies which can be used by mistake while coding. For example, Guava was used in unit test even though it should not be a dependency of Uyuni (which is addressed in this PR as well). Moreover, the presence of Saxon in the CheckStyle jar meant that, during the execution of unit tests, it was used in place of Xalan.

Finally, this PR also contains a small refactoring, moving class SparkTestUtils to com.redhat.rhn.testing (the package currently used for test utility classes) and moving ResponseMappersTest to test.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

• DONE

Test coverage

• No tests: only build related refactorings

• 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]

Suggested tests to cover this Pull Request

• min_rhlike_openscap_audit
• min_deblike_openscap_audit
• srv_menu
• min_salt_openscap_audit

[mackdk]

Test ScapManagerTest.testXccdfEvalTransformXccdfWithTailoring is now failing due to the change in the XML transformer.

What happens is that before the classpath fix, the test at runtime was using class net.sf.saxon.jaxp.TransformerImpl from Saxon to implement the xlst transformation, but now it's using org.apache.xalan.transformer.TransformerImpl (which should be the correct one since at runtime we don't have Saxon).

The result is that in the final xml produced by the XSLT transformation the <profile> tag does not contain the expected title attribute:

BEFORE, with Saxon:

<benchmark-resume id="xccdf_org.ssgproject.content_benchmark_SLE-15" version="0.1.58">
    <profile title="Tailored profile" id="xccdf_org.ssgproject.content_profile_cis_suse_test"/>
    ...

AFTER, with Xalan:

<benchmark-resume id="xccdf_org.ssgproject.content_benchmark_SLE-15" version="0.1.58">
    <profile id="xccdf_org.ssgproject.content_profile_cis_suse_test"/>
    ...

So it seems that the profile part of the XSLT used in the test is no longer working as expected.

[cbosdo]

Test ScapManagerTest.testXccdfEvalTransformXccdfWithTailoring is now failing due to the change in the XML transformer.

What happens is that before the classpath fix, the test at runtime was using class net.sf.saxon.jaxp.TransformerImpl from Saxon to implement the xlst transformation, but now it's using org.apache.xalan.transformer.TransformerImpl (which should be the correct one since at runtime we don't have Saxon).

The result is that in the final xml produced by the XSLT transformation the <profile> tag does not contain the expected title attribute:

It probably means we need to implement this properly. Whether this is only in the test or in the production code is another story. Just mind that we probably will switch from Xalan to Saxon10+ in the mid term.

[mackdk]

It probably means we need to implement this properly.

Actually after further testing this turned out to be a Xalan 2.7.2 bug. The XSLT is valid and works with any other XSLT processor.

Basically, when turning on FEATURE_SECURE_PROCESSING, Xalan discards all foreign attributes. This has not been fixed in the official Xalan and 2.7.3 still has the same issue, but a patched version exists within the org.apache.servicemix.bundles project: apache/servicemix-bundles@d72fcbe

Can this XSLT be customized by the user? If not, a workaround would be to change the XSLT from:

<profile title="Tailored profile">
    <xsl:attribute name="id">
        <xsl:value-of select="$profileId"/>
    </xsl:attribute>
</profile>

to

<profile>
    <xsl:attribute name="id">
        <xsl:value-of select="$profileId"/>
    </xsl:attribute>
    <xsl:attribute name="title">Tailored profile</xsl:attribute>
</profile>

[cbosdo]

It probably means we need to implement this properly.

Actually after further testing this turned out to be a Xalan 2.7.2 bug. The XSLT is valid and works with any other XSLT processor.

Basically, when turning on FEATURE_SECURE_PROCESSING, Xalan discards all foreign attributes. This has not been fixed in the official Xalan and 2.7.3 still has the same issue, but a patched version exists within the org.apache.servicemix.bundles project: apache/servicemix-bundles@d72fcbe

Can this XSLT be customized by the user? If not, a workaround would be to change the XSLT from:

<profile title="Tailored profile">
    <xsl:attribute name="id">
        <xsl:value-of select="$profileId"/>
    </xsl:attribute>
</profile>

to

<profile>
    <xsl:attribute name="id">
        <xsl:value-of select="$profileId"/>
    </xsl:attribute>
    <xsl:attribute name="title">Tailored profile</xsl:attribute>
</profile>

I would just rollback the change adding the FEATURE_SECURE_PROCESSING. I'm not sure it actually addresses the original issue with external DTDs / Schema and seems buggy in Xalan. The idea is to switch to Saxon 10+ as soon as we have the package available.

[mackdk]

Disabled secure processing as suggested by Cedric.