The nice thing I see with OBR is that the resolution is much closer to the real environement, as OBR takes into account the already deployed bundles. For example if you try to install camel-blueprint on Karaf 2.1, the whole environment is kinda messed up because you end up with two versions of the aries blueprint implementation (which does not work very well). Ideally, the camel-blueprint feature would put a requirement on a blueprint extender being present, and this requirement would be solved by the current environment, so obr would not try to install another version of blueprint.
In our case, for camel-jaspyt, it 's not very easy to model (though it's possible), but I honestly thing this is a very rare case. The way to model that would be to have the camel-jasypt bundle (or is it the jasypt bundle itself?) have a requirement on a specific capability, let's say "foo" which happen to be provided by the iucla bundle and also by the system bundle (or the environment) if running on jdk6. Though, IIUC it does not really harm to install icu4j even on JDK 6, so at worst, there's an unused bundle in the system. On Tue, Oct 12, 2010 at 08:25, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Guillaume, > > Where to put the bundle resolution logic in the OBR ? > The user should be able to define the bundle set, so maybe the easiest > location is the feature descriptor. > > I know that the OBR supports properties on repo, but the user will have to > "tune" the repo to add some properties for bundle provisioning. > > I wonder what the easiest way for the user to define it. > > Regards > JB > > > On 10/12/2010 08:10 AM, Guillaume Nodet wrote: > >> I'm not sure we should add too much of this in the features >> descriptors. I think a better idea would be to start leveraging OBR >> to determine the best set of dependencies for a given set of bundles >> to install. If needed we could also leverage the obr url handler to >> use a filter to actually select a bundle. >> >> On Tuesday, October 12, 2010, Jean-Baptiste Onofré<j...@nanthrax.net> >> wrote: >> >>> Hi Claus, >>> >>> Up to now, AFAIK, it's not possible to define a feature with JDK specific >>> bundles (the descriptor is static). You can add some JRE/JDK specific >>> definition in etc/jre.properties but it's global to the kernel (not >>> dedicated to a given feature). >>> >>> Anyway, I think it's interesting. >>> >>> We can extend the feature deployer to support this kind of "conditions". >>> >>> I'm gonna raise a Jira task around this. >>> >>> Regards >>> JB >>> >>> On 10/12/2010 06:16 AM, Claus Ibsen wrote: >>> >>> Hi >>> >>> I wonder if its possible in the features.xml file to define a bundle >>> being qualified depending on the current JDK? >>> >>> For example if you run JDK 1.5 you want the bundle included. If you >>> run JDK 1.6+ you do NOT. >>> The option should most likely support a range similar to the OSGi >>> versioning. >>> >>> Maybe something similar to this: >>> <bundle jdk="[1.5,1.6)">mvn:xxx/yyy/2.2</bundle> >>> >>> An example would be many of the encryption frameworks which requires >>> additional jars to run on JDK 1.5, where as 1.6 provides API and >>> chipers out of the box. >>> And we could have a similar situation when JDK 1.7 comes out. Where >>> you may need additional JARs on 1.6 and not on 1.7. >>> >>> I could not find such information at >>> http://karaf.apache.org/46-provisioning.html >>> >>> But it could be the documentation is outdated >>> >>> >>> >>> >> -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
