On Tue, Oct 12, 2010 at 8:55 AM, Guillaume Nodet <[email protected]> wrote: > 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. >
Thanks for the detailed response. Looks great if the OBR gets smarter for blueprint and the likes which are more natural fit into OSGi. Yeah the camel-jasypt is most likely a corner case, and JDK 1.5 is on the decline. We can just create a camel-jasypt-jdk15 feature which has that additional bundle. Then end users can install that when running on JDK 1.5. > On Tue, Oct 12, 2010 at 08:25, Jean-Baptiste Onofré <[email protected]> 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é<[email protected]> >>> 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 > > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
