[
https://issues.apache.org/jira/browse/XALANJ-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791952#comment-17791952
]
Joe Kesselman commented on XALANJ-2713:
---------------------------------------
Absolutely agreed. Shipping the dependencies with Xalan in the .bin.tar.gz
distribution file makes sense; we do that with other packages. Copying into the
jarfiles does not unless repackaged, and even that is generally not desirable
these days.
I've marked most other dependencies as <provided>. I just missed these because
they had been there before and my diff-the-content-lists check therefore didn't
call them to my attention.
I'm trying to stay out of your way in xalan-java right now. Would you prefer I
make this change to the pom and you rebase, or you make it and I will?
> 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: [email protected]
For additional commands, e-mail: [email protected]
