I agree these should be either shaded or provided separately. They are required for our bytecode compiler, and regex is probably also used in interpretive mode, but I believe we can call them dependencies. They might want to be included in the binary distribution zips, and of course be available when testing; I don't _think_ we should be copying them in; if we must, shading is absolutely appropriate.
I will double-check how the Ant build handled these. I could swear I had previously removed these from our jarfile by (ab)using maven's "provided" flag... -- /_ 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: Alexander Kriegisch (Jira) <j...@apache.org> Sent: Tuesday, November 28, 2023 12:10:00 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: [jira] [Updated] (XALANJ-2713) Relocate dependencies shaded into XalanJ JARs [ https://issues.apache.org/jira/browse/XALANJ-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kriegisch updated XALANJ-2713: ---------------------------------------- Description: Currently, the {{xalan:xalan}} artifact contains classes from * {{org.apache.bcel:bcel}}, * {{com.github.vbmacher:java-cup-runtime}}, * {{regexp:regexp:jar:1.3}}. The question whether that makes sense at all instead of letting users rely on dependencies defined in POMs is separate from this issue. Maybe, it is necessary to build a stand-alone version of Xalan, usable as a command line tool. I am not a Xalan user, so I do not know. For use as a library, it is definitely unnecessary with modern build management tools like Maven or Gradle. Either way, the classes are shaded into the Xalan JAR (I checked version 2.7.1), but not relocated, e.g. from {{org.apache.bcel}} to {{org.apache.xalan.bcel}}. I.e., any consuming project which itself uses any of the shaded, unrelocated libraries might experience problems with duplicate classes on the class path, making it a lottery which ones are found in case of non-identical versions. This can lead to all sorts of problems, ranging from compilation issues to weird, hard to debug runtime behaviour. Therefore, I suggest to relocate third-party dependencies in future releases. Even though it might be a breaking change for users naively relying on the existence and and actively using the embedded dependency classes, even though their original libraries are not actually on the class path, this should be done and clearly documented in the release notes. Those users could then either change their package name imports to the newly relocated ones or simply add their own dependencies to those libraries, if they use them outside a Xalan context. [~jkesselm], I have created this issue, because our related discussion in https://github.com/apache/xalan-java/pull/132 is actually off topic. My own fault to start it there, sorry. was: Currently, the {{xalan:xalan}} artifact contains classes from * {{org.apache.bcel:bcel}}, * {{com.github.vbmacher:java-cup-runtime}}, * {{regexp:regexp:jar:1.3}}. The question whether that makes sense at all instead of letting users rely on dependencies defined in POMs is separate from this issue. Maybe, it is necessary to build a stand-alone version of Xalan, usable as a command line tool. I am not a Xalan user, so I do not know. For use as a library, it is definitely unnecessary with modern build management tools like Maven or Gradle. Either way, the classes are shaded into the Xalan JAR (I checked version 2.7.1), but not relocated, e.g. from {{org.apache.bcel}} to {{org.apache.xalan.bcel}}. I.e., any consuming project which itself uses any of the shaded, unrelocated libraries might experience problems with duplicate classes on the class path, making it a lottery which ones are found in case of non-identical versions. This can lead to all sorts of problems, ranging from compilation issues to weird, hard to debug runtime behaviour. Therefore, I suggest to relocate third-party dependencies in future releases. Even though it might be a breaking change for users naively relying on the existence and and actively using the dependency classes, even though their original libraries are not actually on the class path, this should be done and clearly documented in the release notes. [~jkesselm], I have created this issue, because our related discussion in https://github.com/apache/xalan-java/pull/132 is actually off topic. My own fault to start it there, sorry. > Relocate dependencies shaded into XalanJ JARs > --------------------------------------------- > > Key: XALANJ-2713 > URL: https://issues.apache.org/jira/browse/XALANJ-2713 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan > Affects Versions: 2.7.3 > Reporter: Alexander Kriegisch > Assignee: Gary D. Gregory > Priority: Major > > Currently, the {{xalan:xalan}} artifact contains classes from > * {{org.apache.bcel:bcel}}, > * {{com.github.vbmacher:java-cup-runtime}}, > * {{regexp:regexp:jar:1.3}}. > The question whether that makes sense at all instead of letting users rely on > dependencies defined in POMs is separate from this issue. Maybe, it is > necessary to build a stand-alone version of Xalan, usable as a command line > tool. I am not a Xalan user, so I do not know. For use as a library, it is > definitely unnecessary with modern build management tools like Maven or > Gradle. > Either way, the classes are shaded into the Xalan JAR (I checked version > 2.7.1), but not relocated, e.g. from {{org.apache.bcel}} to > {{org.apache.xalan.bcel}}. I.e., any consuming project which itself uses any > of the shaded, unrelocated libraries might experience problems with duplicate > classes on the class path, making it a lottery which ones are found in case > of non-identical versions. This can lead to all sorts of problems, ranging > from compilation issues to weird, hard to debug runtime behaviour. > Therefore, I suggest to relocate third-party dependencies in future releases. > Even though it might be a breaking change for users naively relying on the > existence and and actively using the embedded dependency classes, even though > their original libraries are not actually on the class path, this should be > done and clearly documented in the release notes. Those users could then > either change their package name imports to the newly relocated ones or > simply add their own dependencies to those libraries, if they use them > outside a Xalan context. > [~jkesselm], I have created this issue, because our related discussion in > https://github.com/apache/xalan-java/pull/132 is actually off topic. My own > fault to start it there, sorry. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
