Hi, Currently there is an implementation of org.apache.jackrabbit.api.security.JackrabbitAccessControlEntry and org.apache.jackrabbit.api.security.JackrabbitAccessControlList in org.apache.jackrabbit.jcr2spi.security.authorization.jackrabbit.acl.AccessControlEntry[1]/AccessControlList[2]. In case jcr2spi is deployed in an OSGi container this leads to a narrow import-version ranges on the Jackrabbit API package org.apache.jackrabbit.api.security which is a problem, because that package gets a new major version quite frequently [4].
Is this supposed to be like this according to Jackrabbit SPI architecture[3]? Is the Jackrabbit API really supposed to be implemented in the “Client” part? How can one then deploy a bundle which is compatible with a broad range of Jackrabbit API which is embedding JCR2SPI (like FileVault RCP [5])? Is the Jackrabbit API then supposed to be embedded as well (and not reused from the existing OSGi container)? Thanks for any input here, Konrad [1] - https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/security/authorization/jackrabbit/acl/AccessControlEntryImpl.java [2] - https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/security/authorization/jackrabbit/acl/AccessControlListImpl.java [3] - https://jackrabbit.apache.org/jcr/components/jackrabbit-spi.html [4] - https://github.com/apache/jackrabbit-oak/commits/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/package-info.java [5] - https://github.com/apache/jackrabbit-filevault/tree/master/vault-rcp
