sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (JIRA)" <>
Subject [jira] [Commented] (SLING-8404) Provide an API-JAR for the XSS Protection API
Date Fri, 10 May 2019 11:06:00 GMT


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:
>             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 exports only one package,,
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Ā 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 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
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

View raw message