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 Wed, 20 Oct 2010 10:17:56 GMT
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

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