jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-6069) Modularisation of Oak
Date Tue, 28 Aug 2018 12:17:03 GMT

     [ 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.9

> 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.9
>
>
> 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)

Mime
View raw message