[OAK-3842] Adjust package export declarations

• Type: Task
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Fix Version/s: 1.3.15, 1.4
• Labels: api modularization technical_debt
• Assignee: Michael Dürig
• Reporter: Michael Dürig
• Created: 06/Jan/16 15:31
• Updated: 06/Feb/20 10:26
• Resolved: 27/Jan/16 16:09

Description

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

Issue Links

• breaks: SLING-5475 JcrResourceProviderFactory dependency to NodeObserver fails in oak trunk
• breaks: OAK-6942 Add package export versions for core-spi
• is blocked by: FELIX-5172 Better control over default export version
• is related to: OAK-3919 Properly manage APIs / SPIs intended for public consumption
• relates to: OAK-3863 [oak-blob-cloud] Incorrect export package
• relates to: OAK-3919 Properly manage APIs / SPIs intended for public consumption
• relates to: OAK-6945 Add package export versions for oak-commons