Hi, 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 BR, Jukka Zitting
