(See https://issues.apache.org/jira/browse/XALANJ-2436)
At the moment, Xalan -- even the Maven build -- is still importing bcel and regexp into its jarfiles without renaming/"shading" them.
While XALANJ-2436 expresses the problem in terms of Endorsed Classpath (which is no longer needed since Sun shaded their copy of Xalan and the javax/JAXP/TrAX interfaces select between implementations via a properties setting), it is potentially a general issue. With this setup, if there are conflicting implementations available, it may be impossible for a user to select both the desired version of Xalan and the desired version of these dependencies.
There are only a few clean solutions. Simplest first:#1) Make these packages external dependencies for Xalan, as are so many other packages. Advantage: Free ability to mix and match versions. Disadvantage: It's possible to run into incompatibilities as packages are independently upgraded. The various version-dependency systems are *supposed* to be able to manage this, but don't always.
#2) Shade these packages, renaming Xalan's copy of them (exactly as Sun shades Xalan itself to avoid having their possibly-outdated convenience copy conflict with ours). Advantage: Xalan always runs with a known version of these tools, and user doesn't have to supply them. Disadvantage: If user wants to override Xalan's use of that binding, they need to provide a new shaded copy of the library; merely putting the standard jarfile earlier on the classpath isn't sufficient.
#3) Have Xalan run in an independent classloader, OSGi-style. Advantage: Doesn't require renaming, but still isolates Xalan's choice of library version from that of the rest of the application. Also, opens the opportunity for OSGi demand-loading, which can significantly improve efficiency by not bringing in any classes not actually in use. Disadvantage: Complexity, potential user confusion when debugging, and major implementation effort to get the full benefit.
#Ugh) We *could* leave it as it is. I don't consider that a clean solution, but it is a solution. It's no worse than we have been, but no better... and given how many other external dependencies we have, I have trouble justifying these two being special cases worth embedding.
I think we need to make an architectural decision on this. As I say, I currently prefer #1. That *would* mean Xalan users would have to be aware of and provide these dependencies, which would be a change from past releases. But it's really not different from our dependencies upon Xerces or other external packages.
And I don't see a good reason to continue embedding without renaming; this feels like a tradition we should break.
-- ` /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. Feel free to call him on it.
OpenPGP_0xFFBAFF963D937815.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
