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/xalan/pom.xml at master · apache/xalan-java github.com <dependency> <groupId>regexp</groupId> <artifactId>regexp</artifactId> <version>1.3</version> </dependency> 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>
