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
