Hi, On Mon, May 7, 2012 at 9:02 AM, Thomas Mueller <[email protected]> wrote: > I guess you wanted to write "non-OSGi" instead of "plain Java"?
Essentially yes, but there's a subtle point here. Let me explain. A specific "non-OSGi" setup could be something like repository.xml -based configuration mechanism we have in Jackrabbit 2.x. Even though it's possible deploy Jackrabbit 2.x in OSGi, J2EE and other kinds of environments, the wiring and configuration of internal components is only really possible through the repository.xml file. This leads to inflexibility and workarounds like we've seen in JCR-1412 [1]. So instead of saying that we support "OSGi" and "non-OSGi" deployments, I'd like to set the baseline to "plain Java". It should be possible to construct any Oak configuration with nothing but normal constructors, setters and (where needed) simple lifecycle methods like init()/close(). No interpretation of XML files or even custom "configuration URLs" should be needed for such a setup. As long as that's possible, it'll be easy to support any kinds of more advanced deployment and configuration mechanisms, be they OSGi or not. Apache Tika is a good example of such a design in action. Out of the box Tika supports OSGi deployments, the Java SPI mechanism, and custom "tika-config.xml" configuration files. And people have wired Tika in to all kinds of other configurations. None of this is really necessary for using Tika, as you can just as well simply construct a collection of Tika components and wire them together plain Java code. PS. Note that this only covers one aspect of a component model. The other one is to design component interfaces in a way that makes them easy to compose and allows dynamic deployment environments like OSGi to add or remove components at runtime. [1] https://issues.apache.org/jira/browse/JCR-1412 BR, Jukka Zitting
