[
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 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.
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 of 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, 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 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.
--
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
