karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: Features and OBR
Date Wed, 20 Oct 2010 07:32:43 GMT
It sounds good.


On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré <jb@nanthrax.net>wrote:

> 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
>>>
>>>
>>
>>
>>


-- 
*Ioannis Canellos*
http://iocanel.blogspot.com

Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message