Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.216.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=nK3Zo+Lq3aUKOBEyF/ZhpcsWchnBtEBBVbWVNrHXM90gONje6/nBgix+E2RxIymLDQ
         WpVah0a5s1FWdzYl9GZDJUCVD/RmGHthKMTv8faxYgF+kouPkB2KXvVPt8Zi2qLLneXF
         V55YEUL1dS5gHScUcpHzgjwRbEbmo2zRHGkTc=
MIME-Version: 1.0
In-Reply-To: <AANLkTin+HCNGox9J2X6_p7XvYN2joi5b1-ajq9mVrZPU@mail.gmail.com>
References: <AANLkTikQiz8-fJms-nmBsKh86tZqK2L4PeykYO0pSs6u@mail.gmail.com>
 <C8D30016-4758-4EB9-A171-00B3059106E9@yahoo.com>
 <AANLkTikEoVN4_EZxzkCv_RGfFgn52jq-Ps5kvuYh7AMU@mail.gmail.com>
 <AANLkTin+HCNGox9J2X6_p7XvYN2joi5b1-ajq9mVrZPU@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Wed, 27 Oct 2010 17:20:14 +0200
Message-ID: <AANLkTik6qVR6s=wqKkqn+HA-EDEjhUP=eptEvD8SLnwU@mail.gmail.com>
Subject: Re: Features and OBR
To: dev@karaf.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

Just a heads up. Looking forward to when this is in place in Karaf.

Have been working on fixing the issues having Camel features.xml
overlap some basic features from Karaf such as http, spring,
spring-dm.
But I hit the issue that Camel is on Spring 3.0.4 and Karaf 2.1 is on
Spring 3.0.3.

Anyway knowing that this makes it into Karaf, it should allow us to
remove the: spring, spring-dm and http features form Camel and rely on
Karaf.
Which means the Camel features are 100% Camel components only.


On Wed, Oct 20, 2010 at 1:02 AM, Guillaume Nodet <gnodet@gmail.com> wrote:
> I think I have a solution to partially solve the problem. =A0Of the main
> interest in OBR imho is that it knows what is installed in the framework
> already, so it can be used to avoid duplicating libraries in different
> versions that are not needed (if you need spring-core 3.0.3 but spring-co=
re
> 3.0.4 is installed, there's no need to install both usually).
> The problem is that the use of OBR usually require OBR repositories. =A0 =
I
> think I can get rid of that by creating a dummy OBR repository from the
> features descriptors and flagging some bundles in the features descriptor=
 as
> optional (or dependencies).
>
> For example, in the current descriptor repoitory we have:
>
>
> =A0 =A0<feature name=3D"jasypt-encryption" version=3D"2.1.99-SNAPSHOT">
>
> =A0<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundle=
s.commons-codec/1.3_3</bundle>
>
> =A0<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundle=
s.commons-lang/2.4_4</bundle>
>
> =A0<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundle=
s.jasypt/1.6_1</bundle>
>
> =A0<bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-=
SNAPSHOT</bundle>
> =A0 =A0</feature>
>
> But really, the key bundle here is
> the mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHO=
T
> one, whereas the three others are just dependency whith versions that cou=
ld
> be changed (provided they are still in the required range). =A0This would=
 mean
> that if commons-lang-2.5 has already been installed through another featu=
re,
> there's no need to install another version of it.
>
> In addition, I think supporting dependency on feature ranges would be rea=
lly
> important as it would help greatly when depending on spring 2.x or 3.x fo=
r
> example.
>
> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet <gnodet@gmail.com> wrote:
>
>> That could be a good way. =A0I haven't experimented that really, but I
>> think it would at least give the freedom to the resolver to reuse
>> locally installed bundles, so that's obviously a really good start.
>>
>> As for OBR itself, I've added to the maven bundle plugin a goal that
>> can be used to build an obr repository out of a maven repository in a
>> directory. =A0This goal can also generated maven urls instead of the
>> file:// urls that it would give. =A0Thus giving an additional
>> indirection in the url instead of pointing directly to the http
>> location.
>>
>> I think from a production pov, what would be needed is some kind of
>> maven repository (nexus or archiva) coupled with an OBR repository.
>> This way, the deployer would be responsibe for adding authorized
>> artifacts in the repository and that would automatically update an obr
>> repository descriptor with the added artifacts.
>> The problem is that this way of seeing the problem does not work well
>> in a non controlled environment such as most users do when they allow
>> access to maven central ... So in that case, your approach of using
>> the maven dependencies could be a good solution.
>>
>> On Fri, Jul 2, 2010 at 18:34, David Jencks <david_jencks@yahoo.com> wrot=
e:
>> >
>> > On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>> >
>> >> I've just added support for pluggable resolvers for features.
>> >> I've also created an OBR based resolver that is installed with the ob=
r
>> feature.
>> >>
>> >> Now you can do the following:
>> >>
>> >> =A0<feature name=3D"xx" version=3D"yy" resolver=3D"obr">
>> >>
>> =A0<bundle>bundle:(&(symbolicname=3Dorg.apache.camel.camel-blueprint)(ve=
rsion>=3D2.4.0)(version<2.4.1))</bundle>
>> >> =A0</feature>
>> >>
>> >> If OBR has been configured with the needed repositories, it will
>> >> install camel-blueprint bundle with all the required dependencies.
>> >> The benefit is that you don't have to specify all the dependencies,
>> >> but only the key bundles. =A0The added benefit is that the deployment
>> >> will leverage what is already installed and you don't have to maintai=
n
>> >> an homogeneous set of repositories (for example, you should not have
>> >> to specify which version of spring you want to use and obr will reuse
>> >> the one installed if possible, or choose which one to install based o=
n
>> >> the constraints expressed by the bundles).
>> >>
>> >> I haven't updated the feature descriptor yet, mostly because we don't
>> >> have a obr repository which contain all the bundles we need.
>> >> I have one locally that contain all the bundles present on maven
>> >> central, but it's a bit too big to be used in this context, so not
>> >> sure how to handle that yet.
>> >>
>> >> Anyway, just wanted to give a heads up on that.
>> >
>> >
>> > One of the points of friction I see between maven and osgi is that in
>> maven you explicitly =A0specify which artifacts supply your needed
>> dependencies whereas in osgi they magically appear from something like O=
BR.
>> =A0I've always wondered where the OBR-like info is supposed to come from=
. =A0On
>> the other hand, if you are using maven to build, you have a reasonable s=
et
>> of candidate artifacts in the maven dependencies (assuming they are all
>> bundles).
>> >
>> > Something I started experimenting with in geronimo is to, for each
>> feature, construct an OBR xml file out of the maven dependencies. =A0Jus=
t
>> before you try to install the feature, you add the obr fragment to the O=
BR
>> instance you are using for resolving the feature. =A0This pretty much as=
sures
>> that something that will enable the bundles in the features to resolve w=
ill
>> be available.
>> >
>> > Writing the code for this was easy, but we weren't relying enough on O=
BR
>> at the time to find out how well it works in practice. =A0I have been
>> wondering if anyone else would think this is a reasonable approach to
>> investigate.
>> >
>> > thanks
>> > david jencks
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> Open Source SOA
>> >> http://fusesource.com
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>


--=20
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/