[
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091481#comment-15091481
]
Chetan Mehrotra commented on OAK-3842:
--------------------------------------
After check an Oak based application I can see following packages in use by
other bundles
{noformat}
org.apache.jackrabbit.oak.api
org.apache.jackrabbit.oak.api.jmx
org.apache.jackrabbit.oak.commons
org.apache.jackrabbit.oak.plugins.index.lucene
org.apache.jackrabbit.oak.plugins.observation
org.apache.jackrabbit.oak.spi.commit
org.apache.jackrabbit.oak.spi.security
org.apache.jackrabbit.oak.spi.security.authentication
org.apache.jackrabbit.oak.spi.security.authorization
org.apache.jackrabbit.oak.spi.security.user
org.apache.jackrabbit.oak.spi.security.user.util
org.apache.jackrabbit.oak.spi.state
{noformat}
> 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)
