[ 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)