Yeah, that's exactly what OBR uses to solve this problem, but in this case, the bundle should not be installed on 1.6 (or rather, does not need to be installed), so it's a bit of the opposite way :-(
On Tue, Oct 12, 2010 at 10:30, Ade <[email protected]> wrote: > Can't we just piggy back this stuff on the OSGi 'Execution Environment' > stuff? I don't use it much, but AFAIR a bundle can specify a minimal > execution environment in it's manifest headers. That way, the bundle can > fail gracefully if it's deployed into 1.5 and needs 1.6 and vice versa. > > I'd like to keep the features file as simple as possible for now. > > > On 12/10/2010 08:11, Claus Ibsen wrote: > >> 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 >>> >>> >>> >>> >> >> >> -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
