[ 
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig resolved OAK-3842.
--------------------------------
       Resolution: Fixed
    Fix Version/s:     (was: 1.4)

Applied the updated patch at http://svn.apache.org/viewvc?rev=1727106&view=rev.

For those packages that have been exported at a non zero version before I had 
to add an exclusion filter to the baseline goal. For now I did so in 
{{oak-parent}} for all modules. We can change this to per module exclusions if 
there is a consensus that this would be better. 



> 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: Blocker
>              Labels: api, modularization, technical_debt
>             Fix For: 1.3.15
>
>         Attachments: OAK-3842-2.patch, OAK-3842.patch
>
>
> 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)

Reply via email to