jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3842) Adjust package export declarations
Date Mon, 11 Jan 2016 09:43:39 GMT

    [ 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

View raw message