I'm not sure which version of regexp the Maven build is pulling down; will check.
-- /_ 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. ________________________________ From: Jared Davis <jar...@davisprogramming.com> Sent: Friday, March 29, 2024 11:44:34 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Embedded packages, architectural decision needed The 1.3 version of regexp is known to be buggy. Old email thread "Source of regular expression jar in Xalan 2.7.3 RC9" Jan - April 2023 suggests removing it. <https://github.com/apache/xalan-java/blob/master/xalan/pom.xml> [xalan-java.png] xalan-java/xalan/pom.xml at master · apache/xalan-java<https://github.com/apache/xalan-java/blob/master/xalan/pom.xml> github.com<https://github.com/apache/xalan-java/blob/master/xalan/pom.xml> <dependency> <groupId>regexp</groupId> <artifactId>regexp</artifactId> <version>1.3</version> </dependency> <https://jakarta.apache.org/regexp/changes.html> Jakarta Regexp - Jakarta Regexp History of Changes<https://jakarta.apache.org/regexp/changes.html> jakarta.apache.org<https://jakarta.apache.org/regexp/changes.html> [favicon.ico]<https://jakarta.apache.org/regexp/changes.html> 1.4 from aug 2005 has a critical fix * Fixed Bug 2121<http://issues.apache.org/bugzilla/show_bug.cgi?id=2121>: '.' or '-' in bracket expression gives unexpected results (VG) On Mar 29, 2024, at 11:07 AM, Joseph Kessselman <kesh...@alum.mit.edu> wrote: (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>
