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