Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@gmail.com designates
 72.14.220.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding;
        b=wkd0jC2QJ+5/iDEhdNv4FLdeaLiF6S5uTNrtuCq9FxCzmOCWm4nRjqPpFUgo5yOnFm4w3RvTfKZrGue8oiimia/2W34WVyqCAbGhoPiTRzxz1YpMJgK5cu9ptOpL+DPgEVlccRtwlC2gB3PIGazP465aUcTCT5OeZ16w5pp0Rkc=
Subject: Re: OSGi 1.5
From: Felix Meschberger <fmeschbe@gmail.com>
To: dev@jackrabbit.apache.org
In-Reply-To: <483923BF.5000602@intient.com>
References: <483923BF.5000602@intient.com>
Content-Type: text/plain
Date: Fri, 30 May 2008 07:35:44 +0200
Message-Id: <1212125744.3750.304.camel@bslm-046.corp.day.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

Am Sonntag, den 25.05.2008, 18:30 +1000 schrieb Bradley Beddoes:
> Hi All,
> I have been reading over a few threads and looking at this issue:
> https://issues.apache.org/jira/browse/JCR-1342
> 
> Have checked out the nighly hudson builds and for the components listed 
> in this issue OSGi bundle data is being put into the manifest.
> 
> My question is why is jackrabbit-core and other components not included 
> in this? I would have thought that core in-particular would have been 
> useful as a bundle?.

I 200% agree with you - working on Sling embedding Jackrabbit into the
OSGi framework. This is why I modified two libraries to include the OSGi
manifest headers.

Now, the problem with Jackrabbit-Core is the rich and theoretically open
dependency set (by way of the way it is configured today). You could of
course just add the bundle manifest headers to the build. The resulting
bundle has (virtually) tons of imports. This means you have to provide
bundles in your OSGi framework to satisfy these dependencies.

In Apache Sling I went the other way around and made the bundle
embedding the Jackrabbit repository (jcr/jackrabbit-server) as
self-contained as possible and useful by including many of the
dependency libraries in the bundle. This makes integration a lot easier.
But then, this can of course not be done in the standard build of the
jackrabbit-core library.

Looking at these two options, I am not sure, which is the better one --
and there is another issue coming to my mind: Extensibility and
configuration of an embedded Jackrabbit Repository: When deploying into
an OSGi framework you might want to extend Jackrabbit using OSGi means
such as adding (and updating) persistence managers on-the-fly and of
course you might want to use OSGi Configuration Admin to configure
Jackrabbit.

All this is not possible with the current jackrabbit-core. I would love
to see these extensions come into Jackrabbit and AFAIK there are
thoughts about making jackrabbit-core more OSGi friendly ... but we are
all somewhat time constrained and the main focuse currently is to
implement jackrabbit-core as the JSR-283 RI.

If you want to use jackrabbit in an OSGi framework I suggest you look at
the work we've done in Sling (maybe the respective work more belongs to
Jackrabbit than to Sling ...) or what is available in the Jackrabbit
Spring integration.

Hope this helps.

Regards
Felix