karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Features and OBR
Date Mon, 05 Jul 2010 07:29:55 GMT
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