Francesco Mari created OAK-4239:
-----------------------------------
Summary: 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
Fix For: 1.6
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
(v6.3.4#6332)
