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 10:28:58 GMT
Ahh interesting, I'm gonna make a try.

On 10/20/2010 12:17 PM, Guillaume Nodet wrote:
> I was mostly thinking about versioning at the feature dependency level.
> The mvn url already supports range, so i don't think we need to do anything
> here.
> Afaik, you can already write:
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/[1.3_3,2)
>
> I'll post a bit more later today or tomorrow.
>
> On Wed, Oct 20, 2010 at 09:32, Ioannis Canellos<iocanel@gmail.com>  wrote:
>
>> 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
View raw message