It sounds good.
On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré <[email protected]>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<[email protected]> 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<[email protected]> >>> 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>
