jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [jr3] On pluggability and OSGi (Was: [jr3] Release roadmap)
Date Fri, 24 Feb 2012 09:05:53 GMT
Hi,

Am 23.02.2012 um 17:33 schrieb Jukka Zitting:

> Hi,
> 
> On Thu, Feb 23, 2012 at 4:03 PM, Felix Meschberger <fmeschbe@adobe.com> wrote:
>> Hence I would go with OSGi from Day 0 and use the OSGi Service
>> Registry as the mechanic for pluggability.
> 
> The trouble with OSGi by default is that it brings in a massive and
> pretty complex dependency with it. If you build your code with the
> OSGi service registry in mind, it becomes difficult to run it in any
> other environment, including in a simple JUnit test case. You're
> basically making an assumption that all your deployment environments
> will be OSGi frameworks, which dramatically reduces your potential
> user-base.
> 
> I don't want us to make that assumption. It should IMHO be possible to
> embed the repository implementation to for example an Android app, to
> a Maven plugin or a J2EE CMS without having to OSGify the entire
> application.
> 
> That doesn't mean we couldn't or shouldn't use OSGi for wiring things
> up when the repository *is* deployed to an OSGi environment. Indeed
> that's why I explicitly included those points in the roadmap. It's
> just that we shouldn't make the core architecture depend on constructs
> like ServiceTracker that don't work outside the scope of OSGi.

Hmm, ok, let me rephrase it a bit (still I have OSGi in mind and my absolute requirement is
that JR 3 must be deployable in an OSGi framework more easily than JR2).

Here's my list of requirements :

  * Dependency Injection -- known to be a good thing for testing
      and supported not only by Spring but also by OSGi (Declarative
      Services and Blueprint and other non-standard ones).
  * Clear picture of configuration -- again injected à-la DI.
  * Proper separation of public API/packages and private
      implementation packages.
  * No static factories. These are a pain in standard Java but are
      dreadful in pluggable frameworks.
  * Create bundles from the start. These don't harm but allow us
      to testdrive in OSGi frameworks right away.

Regards
Felix
Mime
View raw message