karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Features and OBR
Date Tue, 26 Oct 2010 08:52:26 GMT
nothing to add, i like it :)

kind regards

On Wed, Oct 20, 2010 at 04:28:21PM +0200, Guillaume Nodet wrote:
> Ok, so i've raise KARAF-251 and KARAF-252 and committed some patches, but
> i'd like to discuss those before closing the jiras.
> 
> So, KARAF-251 is about using range on features.
> I've modified the parser and installation service to allow using ranges when
> specifying a dependency on a feature.
> I've also modified the karaf feature descriptor to leverage that by adding a
> spring2 feature:
> 
>     <feature name="spring" version="2.5.6.SEC01">
>         <bundle
> dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle>
>         <bundle>mvn:org.springframework/spring-core/2.5.6.SEC01</bundle>
>         <bundle>mvn:org.springframework/spring-beans/2.5.6.SEC01</bundle>
>         <bundle>mvn:org.springframework/spring-aop/2.5.6.SEC01</bundle>
>         <bundle>mvn:org.springframework/spring-context/2.5.6.SEC01</bundle>
> 
>  <bundle>mvn:org.springframework/spring-context-support/2.5.6.SEC01</bundle>
>     </feature>
>     <feature name="spring" version="3.0.3.RELEASE">
>         <bundle
> dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle>
>         <bundle>mvn:org.springframework/spring-core/3.0.3.RELEASE</bundle>
>         <bundle>mvn:org.springframework/spring-asm/3.0.3.RELEASE</bundle>
> 
>  <bundle>mvn:org.springframework/spring-expression/3.0.3.RELEASE</bundle>
>         <bundle>mvn:org.springframework/spring-beans/3.0.3.RELEASE</bundle>
>         <bundle>mvn:org.springframework/spring-aop/3.0.3.RELEASE</bundle>
> 
>  <bundle>mvn:org.springframework/spring-context/3.0.3.RELEASE</bundle>
> 
>  <bundle>mvn:org.springframework/spring-context-support/3.0.3.RELEASE</bundle>
>     </feature>
>     <feature name="spring-dm" version="1.2.0">
>         <feature version="[2.5.6,4)">spring</feature>
> 
>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_6</bundle>
>         <bundle>mvn:org.springframework.osgi/spring-osgi-io/1.2.0</bundle>
>         <bundle>mvn:org.springframework.osgi/spring-osgi-core/1.2.0</bundle>
> 
>  <bundle>mvn:org.springframework.osgi/spring-osgi-extender/1.2.0</bundle>
> 
>  <bundle>mvn:org.springframework.osgi/spring-osgi-annotation/1.2.0</bundle>
> 
>  <bundle>mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/2.1.99-SNAPSHOT</bundle>
>     </feature>
> 
> When installing a feature, the dependant features are installed as
> following:
>   * if no version is indicated, it means [0, +oo)
>   * if a version is indicated, the range is closed [x, x]
>   * if a feature matching the range is already installed, use that one
>   * else find the highest version matching the range
> 
> So if you 'features:install spring-dm' it will install spring 3.0.3 by
> default.  If you want to install the 2.5 version, you need to
> 'features:install spring 2.5.6' and then 'features:install spring-dm'.
> 
> The second improvement, KARAF-252 is about leveraging OBR to avoid
> installing duplicate dependencies while not forcing the user into using and
> maintaining OBR repositories.  It can now be done by flagging dependencies
> with a dependency='true' flag and resolver="(obr)".   Note the parentheses
> that mean the obr resolver is optional (so it will default to the previous
> behavior if obr isn't installed and in that case will install all the listed
> bundles).   If obr resolver is present, the feature will be transitively
> resolved by creating an obr repository containing all the listed bundles and
> resolving only the bundles marked as not 'dependency'.  So in the example
> above, the aopalliance bundle is marked as a dependency, so that if another
> aopalliance bundle satisfying the constraint (imported packages, etc...) is
> already installed, it won't be installed.
> 
> Thoughts?
> 
> 
> On Wed, Oct 20, 2010 at 12:17, Guillaume Nodet <gnodet@gmail.com> 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>
> >>
> >
> >
> >
> > --
> > 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