[
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091686#comment-15091686
]
angela commented on OAK-3842:
-----------------------------
[~mduerig] as far as the security packages are concerned: everything that
contains {{spi}} is public and should be exported. the remaining two non-spi
packages:
- org.apache.jackrabbit.oak.security.authentication.ldap
that looks wrong to me; but i am not the author of that code. [~tripod], can
you please explain why this is exported?
- org.apache.jackrabbit.oak.security
this is only needed because oak-jcr (and maybe other modules) hard-code the
{{SecurityProviderImpl}} in the default setup. That implementation has been
replaced by Francesco's implementations in all OSGi-based setups; if i could
wish this would only be used for test-purposes... but as long as we have the
dual-setup mess we probably have to stick with the old/broken implementation.
Not sure if/how we can get rid of that export though I would wish to remove it
asap.
> Adjust package export declarations
> -----------------------------------
>
> Key: OAK-3842
> URL: https://issues.apache.org/jira/browse/OAK-3842
> Project: Jackrabbit Oak
> Issue Type: Task
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Critical
> Labels: api, modularization, technical_debt
> Fix For: 1.4
>
>
> We need to adjust the package export declarations such that they become
> manageable with our branch / release model.
> See http://markmail.org/thread/5g3viq5pwtdryapr for discussion.
> I propose to remove package export declarations from all packages that we
> don't consider public API / SPI beyond Oak itself. This would allow us to
> evolve Oak internal stuff (e.g. things used across Oak modules) freely
> without having to worry about merges to branches messing up semantic
> versioning. OTOH it would force us to keep externally facing public API / SPI
> reasonably stable also across the branches. Furthermore such an approach
> would send the right signal to Oak API / SPI consumers regarding the
> stability assumptions they can make.
> An external API / SPI having a (transitive) dependency on internals might be
> troublesome. In doubt I would remove the export version here until we can
> make reasonable guarantees (either through decoupling the code or stabilising
> the dependencies).
> I would start digging through the export version and prepare an initial
> proposal for further discussion.
> /cc [~frm], [~chetanm], [~mmarth]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
