Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.187 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Fri, 24 Feb 2012 09:05:53 +0000
Subject: Re: [jr3] On pluggability and OSGi (Was: [jr3] Release roadmap)
Thread-Topic: [jr3] On pluggability and OSGi (Was: [jr3] Release roadmap)
Thread-Index: Aczy04TY4QHs5CaRRVulNbgj3jNhQA==
Message-ID: <3F8B868C-D294-420A-930A-E0163A843872@adobe.com>
References: 
 <CAOFYJNakpQWg0jGoi2LWFio9nGzMBLxemNTaJ9t_9i38bXEfWA@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNakpQWg0jGoi2LWFio9nGzMBLxemNTaJ9t_9i38bXEfWA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

Am 23.02.2012 um 17:33 schrieb Jukka Zitting:

> Hi,
>=20
> On Thu, Feb 23, 2012 at 4:03 PM, Felix Meschberger <fmeschbe@adobe.com> w=
rote:
>> Hence I would go with OSGi from Day 0 and use the OSGi Service
>> Registry as the mechanic for pluggability.
>=20
> 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.
>=20
> 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.
>=20
> 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 absolut=
e requirement is that JR 3 must be deployable in an OSGi framework more eas=
ily 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 =E0-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=