[
https://issues.apache.org/jira/browse/SLING-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837193#comment-16837193
]
Konrad Windszus commented on SLING-8404:
----------------------------------------
[~hanspeterstoerr] Thanks for the explanation. I agree that splitting up into
two bundles is the solution here, one API only bundle and one Impl bundle (not
exporting any packages, not supposed to be referenced from external).
Introducing an artificial dependency artifact which is not used at runtime
should be prevented though.
> 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)
