[jira] [Commented] (OAK-3842) Adjust package export declarations

["Michael Dürig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089153#comment-15089153 ] 

Michael Dürig commented on OAK-3842:
------------------------------------


Below my initial findings going through the currently exported packages. I adopted an aggressive approach removing a package export declaration when in doubt. This way having an export declaration really means this package is sufficiently stable such that consumers can rely on it. 

Keep as exported:
{code}
org.apache.jackrabbit.oak.api.jmx
org.apache.jackrabbit.oak.api
{code}

Remove package export declaration:
{code}
org.apache.jackrabbit.oak.commons.benchmark
org.apache.jackrabbit.oak.commons.cache
org.apache.jackrabbit.oak.commons.concurrent
org.apache.jackrabbit.oak.commons.io
org.apache.jackrabbit.oak.commons.jmx
org.apache.jackrabbit.oak.commons.json
org.apache.jackrabbit.oak.commons
org.apache.jackrabbit.oak.commons.sort
org.apache.jackrabbit.oak.json
org.apache.jackrabbit.oak.management
org.apache.jackrabbit.oak.namepath
org.apache.jackrabbit.oak.osgi
org.apache.jackrabbit.oak
org.apache.jackrabbit.oak.plugins.atomic
org.apache.jackrabbit.oak.plugins.backup
org.apache.jackrabbit.oak.plugins.commit
org.apache.jackrabbit.oak.plugins.identifier
org.apache.jackrabbit.oak.plugins.itemsave
org.apache.jackrabbit.oak.plugins.memory
org.apache.jackrabbit.oak.plugins.name
org.apache.jackrabbit.oak.plugins.nodetype
org.apache.jackrabbit.oak.plugins.nodetype.write
org.apache.jackrabbit.oak.plugins.observation.filter
org.apache.jackrabbit.oak.plugins.observation
org.apache.jackrabbit.oak.plugins.segment.file
org.apache.jackrabbit.oak.plugins.segment.http
org.apache.jackrabbit.oak.plugins.segment
org.apache.jackrabbit.oak.plugins.value
org.apache.jackrabbit.oak.plugins.version
org.apache.jackrabbit.oak.query.fulltext
org.apache.jackrabbit.oak.query
org.apache.jackrabbit.oak.spi.commit
org.apache.jackrabbit.oak.spi.gc
org.apache.jackrabbit.oak.spi.lifecycle
org.apache.jackrabbit.oak.spi.query
org.apache.jackrabbit.oak.spi.state
org.apache.jackrabbit.oak.spi.whiteboard
org.apache.jackrabbit.oak.spi.xml
org.apache.jackrabbit.oak.stats
org.apache.jackrabbit.oak.util
org.apache.jackrabbit.oak.jcr
{code}

The following packages need further review:

{code}
org.apache.jackrabbit.oak.plugins.lock
{code}
This one is sufficiently stable so we could export it. The question is whether we want 
to export it. [~anchela] WDYT?

{code}
org.apache.jackrabbit.oak.spi.security.authentication.external.basic
org.apache.jackrabbit.oak.spi.security.authentication.external
org.apache.jackrabbit.oak.security.authentication.ldap
org.apache.jackrabbit.oak.spi.security.authorization.cug
org.apache.jackrabbit.oak.security
org.apache.jackrabbit.oak.spi.security.authentication.callback
org.apache.jackrabbit.oak.spi.security.authentication
org.apache.jackrabbit.oak.spi.security.authentication.token
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol
org.apache.jackrabbit.oak.spi.security.authorization
org.apache.jackrabbit.oak.spi.security.authorization.permission
org.apache.jackrabbit.oak.spi.security.authorization.restriction
org.apache.jackrabbit.oak.spi.security
org.apache.jackrabbit.oak.spi.security.principal
org.apache.jackrabbit.oak.spi.security.privilege
org.apache.jackrabbit.oak.spi.security.user.action
org.apache.jackrabbit.oak.spi.security.user
org.apache.jackrabbit.oak.spi.security.user.util
{code}
[~anchela], could you do the analysis for the security related packages as you are the one who know their ways around best in this area. 

{code}
org.apache.jackrabbit.oak.plugins.tree
{code}
[~anchela], do we want /need to export this? I think it is sufficiently stable. 

{code}
org.apache.jackrabbit.oak.spi.blob
org.apache.jackrabbit.oak.spi.blob.stats
{code}
[~amitjain], could you do the analysis for the blob packages?

{code}
org.apache.jackrabbit.oak.plugins.index.aggregate
org.apache.jackrabbit.oak.plugins.index.counter.jmx
org.apache.jackrabbit.oak.plugins.index.counter
org.apache.jackrabbit.oak.plugins.index.fulltext
org.apache.jackrabbit.oak.plugins.index.nodetype
org.apache.jackrabbit.oak.plugins.index
org.apache.jackrabbit.oak.plugins.index.property.jmx
org.apache.jackrabbit.oak.plugins.index.property
org.apache.jackrabbit.oak.plugins.index.reference
{code}
[~chetanm], could you do the analysis for the index packages?

{code}
org.apache.jackrabbit.oak.plugins.index.lucene
org.apache.jackrabbit.oak.plugins.index.lucene.score
org.apache.jackrabbit.oak.plugins.index.lucene.spi
org.apache.jackrabbit.oak.plugins.index.lucene.util
org.apache.jackrabbit.oak.plugins.index.solr.configuration
org.apache.jackrabbit.oak.plugins.index.solr.index
org.apache.jackrabbit.oak.plugins.index.solr.query
org.apache.jackrabbit.oak.plugins.index.solr.server
org.apache.jackrabbit.oak.plugins.index.solr.util
{code}
[~teofili], could you do the analysis for the lucene/solr packages?


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