You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Davide Giannella (JIRA)" <ji...@apache.org> on 2018/11/01 11:26:02 UTC

[jira] [Updated] (OAK-6069) Modularisation of Oak

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

Davide Giannella updated OAK-6069:
----------------------------------
    Fix Version/s: 1.9.11

> Modularisation of Oak
> ---------------------
>
>                 Key: OAK-6069
>                 URL: https://issues.apache.org/jira/browse/OAK-6069
>             Project: Jackrabbit Oak
>          Issue Type: Epic
>          Components: core
>            Reporter: angela
>            Priority: Major
>              Labels: modularization
>             Fix For: 1.10, 1.9.10, 1.9.11
>
>
> Epic to track individual steps towards improved modularisation of Oak
> Until now Oak modules are all released together, which has some drawbacks. Work on the modules must be somewhat kept in lockstep. Releasing a fix for a module means all other modules must be in a state that can be released as well. For a user it may be desirable to just update a single module to get a fix and not a complete set of Oak bundles.
> The general approach for this epic should be to modularize only as needed and not split everything. Obvious candidates are stable interfaces like Oak and NodeStore API and NodeStore implementations.
> This requires fixing potential circular dependencies between logical modules we want to split up. We need a better distinction between the interface part of the SPI and its implementations. Utilities and commons code must be reviewed and potentially moved.
> The oak-it related dependencies should be reconsidered and that a development version of a NodeStore implementation can run integration tests. With the current dependency setup a release of the NodeStore implementation is required first to run the integration tests with those changes.
> Some modules will probably be moved to the top-level and have their own branches and tags.
> To avoid branches it is important to always have trunk stable. Feature work must happen on feature branches, in a forked module or protected with a feature flag until it is ready for prime time. No more unstable work in trunk.
> Module owner is primarily responsible for module releases. At some point there won't be a dedicated person anymore responsible for 'the Oak release'.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)