jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Oak plugin model
Date Tue, 15 May 2012 16:18:31 GMT

When we talk about Oak and about where in our stack a particular piece
of functionality should be implemented, we often tend to approach the
design as a layered stack of components from oak-jcr to oak-core and
on to the underlying implementation. Possible extra features are
usually presented as either new functionality in one of the existing
components or as an extra layer in between or on top of this stack.

This linear top-down view of dependencies seriously limits the
architectural freedom and potential for extensibility we have. I've
brought this up a few times in the context of other discussions, but I
wanted to raise it also as a general concept to make sure we're all on
the same page.

To make this non-layered approach to Oak architecture more obvious, I
outlined this idea in a diagram [1] that shows various potential
features as pluggable extensions. Such an approach provides a nice
third alternative to the kinds of discussions where we've been
debating whether a particular feature (like name mapping, query
parsing, etc.) should be located in oak-jcr or oak-core. By treating
such functionality as pluggable extensions, accessed through well
defined service provider interfaces, we get to keep the main Oak API
clean and simple (e.g. no need for it to cover concepts like a
namespace registry or an abstract query tree) and make the overall
system much more modular and easier to customize.

Ultimately such extra plugin components may well end up as separate
Maven components, but until the related service interfaces and plugin
boundaries are well defined it's better to keep all such code together
and simply use Java package boundaries to separate them. That's the
rationale behind the .oak.plugins package I recently created in
oak-core, and I propose that we'll start moving also other pluggable
parts (like some of the query bits and applicable parts of the recent
security work) there.

[1] http://people.apache.org/~jukka/2012/oak-plugins.png


Jukka Zitting

View raw message