jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (OAK-4239) Encapsulate Oak implementation in a super-bundle
Date Tue, 01 Nov 2016 15:57:58 GMT

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

Francesco Mari resolved OAK-4239.
       Resolution: Won't Fix
    Fix Version/s:     (was: 1.6)

This wish doesn't seem to be relevant at the moment. Resolving this from the time being.

> Encapsulate Oak implementation in a super-bundle
> ------------------------------------------------
>                 Key: OAK-4239
>                 URL: https://issues.apache.org/jira/browse/OAK-4239
>             Project: Jackrabbit Oak
>          Issue Type: Wish
>            Reporter: Francesco Mari
> Oak is currently composed of multiple OSGi bundles, every one of them exposing packages
with a different degree of:
> * visibility: some packages contain API and SPI that should visible to consumers and
extenders of Oak, while other packages contain library code that is supposed to be used only
in Oak.
> * versioning: packages that contain API and SPI use semantic versioning to associate
a meaningful version to the package. Exported packages that contain internal library code
have a meaningless version of {{0.0.0}}.
> This situation is caused by a coupling between the modularization and the deployment
strategies, since they both use the OSGi module layer as a one-size-fits-all solution. This
issue is about decoupling this strategies using two different solutions for modularization
and deployment.
> Regarding modularization, Oak's modules should be:
> * easy to split and merge: splitting a module into two or more modules or merging some
highly coupled modules should be easy.
> * transparent: changing the internal structure of Oak's modules shouldn't have any visible
effect on the users of Oak.
> * easy to release: different parts of Oak grow at a different pace. As such, it doesn't
make much sense to release every module on a bi-weekly bases. A release of a module should
be performed only when that module reaches the desired level of modularity.
> Regarding deployment, when targeting an OSGi environment, Oak should be:
> * encapsulated: Oak shouldn't expose implementation details, internal library code and
private APIs. Internal code is internal.
> * self-contained: some critical dependencies should better be encapsulated in our deployment
unit than provided externally. If a dependency is used in critical code, Oak (and not the
external environment) should be responsible of it.
> * monolithic: Oak should be responsible of combining and wiring its own modules. By hiding
how modules are wired together, we can guarantee a higher degree of quality.
> This issue is about making the following wishes real:
> * stop generating bundles out of every single module. A module should only be a JAR representing
a single, lowly coupled, highly cohesive functionality.
> * release modules only when needed, and only when the module is ready. Apply semantic
versioning extensively.
> * create one super-bundle embedding the independently released modules. This should a
single deployment unit encapsulating Oak's implementation. As much as possible, this should
be an export-nothing bundle. If glue code is needed to link the embedded modules to the OSGi
runtime (e.g. service implementations, configurations, components, etc.), it should be provided
by this bundle.
> * create an additional API bundle if we expose non-standard APIs that are not part of
the JCR specification. The API bundle should be semantically versioned.
> * create an additional SPI bundle if we expose non-standard ways to extend the behavior
of Oak using custom code. The SPI bundle should be semantically versioned.
> /cc [~mduerig], [~edivad]

This message was sent by Atlassian JIRA

View raw message