karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Features and OBR
Date Wed, 20 Oct 2010 07:18:11 GMT
Hi Guillaume

+1 to support dependency on features range.
Anyway, the dependency resolution is already performed by the bundle (if 
it uses Import-Package statement with a version range, for instance, in 
your exemple org.apache.commons.lang;version="[2.4,2.5)").

I guess that we need to "construct" the URL compatible with PAX URL 
before delegating to PAX. The bundle will be added in the OBR 
repositories (locally to Karaf) with a "dependency" flag.

The question is how to upgrade the descriptor repository to work like this.

I propose:
1/ the bundle version could be optional as:
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
In that case, Karaf will looking for the OBR to get an existing 
commons-lang bundle. It fails if the bundle is not present in the OBR
2/ define a bundle version range as
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
In that case, Karaf will looking for the OBR to get the first bundle 
matching the version range.
3/ define the bundle version is still supported (to be backward compatible).

What do you think ?

Regards
JB

On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
> I think I have a solution to partially solve the problem.  Of 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-core
> 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.   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:
>
>
>      <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
>
>   <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
>      </feature>
>
> But really, the key bundle here is
> the mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
> one, whereas the three others are just dependency whith versions that could
> be changed (provided they are still in the required range).  This would mean
> that if commons-lang-2.5 has already been installed through another feature,
> there's no need to install another version of it.
>
> In addition, I think supporting dependency on feature ranges would be really
> important as it would help greatly when depending on spring 2.x or 3.x for
> example.
>
> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<gnodet@gmail.com>  wrote:
>
>> That could be a good way.  I 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.  This goal can also generated maven urls instead of the
>> file:// urls that it would give.  Thus 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>  wrote:
>>>
>>> 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 obr
>> feature.
>>>>
>>>> Now you can do the following:
>>>>
>>>>   <feature name="xx" version="yy" resolver="obr">
>>>>
>>   <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>>>>   </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.  The added benefit is that the deployment
>>>> will leverage what is already installed and you don't have to maintain
>>>> 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 on
>>>> 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  specify which artifacts supply your needed
>> dependencies whereas in osgi they magically appear from something like OBR.
>>   I've always wondered where the OBR-like info is supposed to come from.  On
>> the other hand, if you are using maven to build, you have a reasonable set
>> 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.  Just
>> before you try to install the feature, you add the obr fragment to the OBR
>> instance you are using for resolving the feature.  This pretty much assures
>> that something that will enable the bundles in the features to resolve will
>> be available.
>>>
>>> Writing the code for this was easy, but we weren't relying enough on OBR
>> at the time to find out how well it works in practice.  I 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
>>
>
>
>

Mime
View raw message