WIP: reduce use of xalan

[pjfanning]

Description

See:

• remove xalan dependency due to it being end of life #5690
• https://bz.apache.org/bugzilla/show_bug.cgi?id=66171

This is a POC - if the changes look like a valid way forward, I can put more effort in.
Some tests are failing and will be investigated
Probably need some new tests too
The ant build.xml needs changes - is Ant still used?

Motivation and Context

• Xalan releases are infrequent.
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34169 is not fixed

How Has This Been Tested?

unit tests

Screenshots (if appropriate):

Types of changes

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Probably not a huge deal. Main worry is that some XPath expressions may not behave exactly the same as before. Another issue is that PropertiesBasedPrefixResolver and PropertiesBasedPrefixResolverForXpath2 are public classes that extend a xalan interface (PrefixResolver) - this POC removes the use of that xalan interface.

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.

[FSchumacher]

Ant is still used to generate our docs. I think all xalan related stuff can be deleted safely.

[FSchumacher]

I will take merge test into our current test suite, as it passes with our current code, too :)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 55.48780% with 73 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.19%. Comparing base (b73f690) to head (2cecac4).
⚠️ Report is 567 commits behind head on master.

Files with missing lines	Patch %	Lines
.../org/apache/jmeter/util/PrefixResolverDefault.java	10.71%	25 Missing ⚠️
...rc/main/java/org/apache/jmeter/util/XPathUtil.java	77.27%	15 Missing and 10 partials ⚠️
...che/jmeter/util/PropertiesBasedPrefixResolver.java	11.76%	14 Missing and 1 partial ⚠️
...r/util/PropertiesBasedPrefixResolverForXpath2.java	11.11%	8 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #721      +/-   ##
============================================
- Coverage     55.24%   55.19%   -0.05%     
+ Complexity    10386    10378       -8     
============================================
  Files          1062     1063       +1     
  Lines         65777    65811      +34     
  Branches       7536     7538       +2     
============================================
- Hits          36337    36323      -14     
- Misses        26839    26886      +47     
- Partials       2601     2602       +1     

Files with missing lines	Coverage Δ
...a/org/apache/jmeter/extractor/XPath2Extractor.java	89.15% <ø> (ø)
...rg/apache/jmeter/functions/XPathFileContainer.java	87.09% <ø> (ø)
...r/util/PropertiesBasedPrefixResolverForXpath2.java	40.00% <11.11%> (-60.00%)	⬇️
...che/jmeter/util/PropertiesBasedPrefixResolver.java	18.60% <11.76%> (-11.03%)	⬇️
.../org/apache/jmeter/util/PrefixResolverDefault.java	10.71% <10.71%> (ø)
...rc/main/java/org/apache/jmeter/util/XPathUtil.java	76.98% <77.27%> (-0.06%)	⬇️

... and 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b73f690...2cecac4. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pjfanning]

@FSchumacher thanks for reviewing the changes. The build is now working. I've had to make a few changes to get a few existing tests to pass. Would you be able to review the test changes to see if I've made a change that is dangerous?

[pjfanning]

I raised JetBrains/lets-plot#576 - I'm not sure if that blocks us from making progress here.

[FSchumacher]

Thanks for your work so far on this. Hopefully I will get time to look more into this. So far it looks good to me.
In my tests, I added code to look at the actual used TransformerFactory and set the used spaces and line-breaks for xalan-like and saxon respectively. But that might really be a bit too much.

[FSchumacher]

I raised JetBrains/lets-plot#576 - I'm not sure if that blocks us from making progress here.

That issue has been resolved and we could use the newer releases to get rid of xalan, when we update our dependencies to the next major version of lets-plot, which has changed the API locations. The changes on our side are a few lines of code.

[vlsi]

I see Xalan Java team is not really welcoming contributions. For example, see single-line PRs that say without review, without merge, and even with "not wanted" replies: https://github.com/apache/xalan-java/pulls

So I think we should indeed drop the use of Xalan as they just do not care about the users.