felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BOTTARO Andre RD-MAPS-GRE" <andre.bott...@orange-ftgroup.com>
Subject Backward compatibility
Date Fri, 09 Mar 2007 08:43:31 GMT


It happens that more than a year after the 4th public release of OSGi(tm) specification and
that felix project has begun, there is still an important gap to overcome for oscar developers
to adopt felix platform : 
- The numerous R3 bundles developed before are not deployable as is on the felix platform
whereas the Core specification announce that OSGi(tm) platfroms must be backward compatible
(Manifest version 1 and 2)
- The felix platform is delivered with a bundle repository client which is not compatible
with previous repositories. It is due to obr 2 technical disrupt and felix decision (?) not
to remain backward compatible.

It explains that the choice between R3 and R4 before any development phase is not easy and
I admit that I sometimes recommend to stay on the good old oscar... (especially for quick
developments, quick application tests, or developments with existing R3 bundles).

Some (naive ?) solutions may answer the 2 problems I mention. Tell me if it is reasonable:
- felix Module Class Loader may enable bundles with manifest version 1 to import all the packages
of the boot-delegation classpath. Or even better, a R3 module class loader can be attached
to those bundles.
- oscar bundle repository client may be embedded in the felix one in order for the latter
to be backward compatible. (on this simpler topic, I could recommend using felix with kf bundle
repository client and server...)

I did not check if other platforms treat R3 bundles better. Was the core specification too
ambitious ? 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message