[
https://issues.apache.org/jira/browse/SLING-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835336#comment-16835336
]
Christian Schneider commented on SLING-8404:
--------------------------------------------
The issue is that the dependencies are embedded into the jar.
See
[https://github.com/apache/sling-org-apache-sling-xss/blob/d6f6aaed91e76f79c59ccb47021463a54d7d21b6/pom.xml#L104-L126]
So when you depend on the sling xss jar your code is directly exposed to all
these dependencies without any way to turn them off or tweak the versions. I
see a big value in offering a pure API bundle.
> Provide an API-JAR for the XSS Protection API
> ---------------------------------------------
>
> Key: SLING-8404
> URL: https://issues.apache.org/jira/browse/SLING-8404
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
> Affects Versions: XSS Protection API 2.0.12, XSS Protection API 2.1.8
> Reporter: Hans-Peter Stoerr
> Priority: Minor
>
> The JAR for the org.apache.sling.xss exports only one package,
> org.apache.sling.xss, but embeds loads of dependencies it does not export
> with OSGI. If one needs this as a maven dependency, you get all that unwanted
> stuff in your classpath. In our case it even produced very puzzling compile
> errors, since org.apache.sling.xss included commons-beanutils version 1.7.0,
> and we used a new method from version 1.8.3.
> So, could you please provide an API jar that only contains the
> org.apache.sling.xss package? It's interface is so simple that this wouldn't
> have many dependencies.
> In case someone else has that problem: we worked around that for now by
> setting org.apache.sling.xss to optional and explicitly importing it only
> where that's actually needed in the code. Thus, at least it does not mess up
> the classpaths of the artefacts further down the dependency chain; sometimes
> it had to be included in test scope, though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
