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: mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang 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 mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5) 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: > > > > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3 > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4 > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1 > > mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT > > > 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 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 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: >>>> >>>> >>>> >> bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1)) >>>> >>>> >>>> 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 >> > > >