[
https://issues.apache.org/jira/browse/OAK-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-17.
--------------------------------
Resolution: Fixed
So far Oak fullfills the requirement as captured in excerpt above and Oak can
be configured programatically.
The support for pojo-sr is being tracked in OAK-1522 which should enable OSGi
support outside of OSGi container.
> Modularisation and configuration concept
> ----------------------------------------
>
> Key: OAK-17
> URL: https://issues.apache.org/jira/browse/OAK-17
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, jcr
> Reporter: Michael Dürig
> Assignee: Chetan Mehrotra
> Fix For: 0.19
>
>
> We need to come up with a concept for modularisation and configuration. There
> is some initial discussion on the list [1]. While we need to make sure that
> we are interoperable with OSGi, I don't think we should use OSGi itself for
> the lower granular pieces. That is, for certain subsystems of oak-jcr or
> oak-core for example. Still we need a way for handling dependencies between
> and configuration of implementation classes. In the case of oak-jcr there is
> the GlobalContext class. This is basically poor man's dependency injection
> and I'd like to get rid of it as soon as we have a better solution. What I'd
> like to have on that level is compile time dependency injection such that we
> get loose coupling between implementation classes but don't get the
> additional complexity from run time dependency injection (aka OSGi).
> [1] http://markmail.org/thread/hpssa4r6brlt5cwa
--
This message was sent by Atlassian JIRA
(v6.2#6252)
