[
https://issues.apache.org/jira/browse/XALANJ-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792124#comment-17792124
]
Alexander Kriegisch commented on XALANJ-2713:
---------------------------------------------
I am not sure what change you would have me make. Like I said, previous Xalan-J
versions already included the same dependency classes. First, we need to
establish if they are needed for anything like stand-alone execution. That is a
fork in the road:
* If yes, we can decide to relocate them.
* If no, we can decide to remove them. Next, we would decide whether to produce
an additional artifact which all (not just some) dependencies as part of the
binary distro and optionally on Maven Central.
> 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
