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 RE: [osgi-dev] Backward compatibility
Date Fri, 09 Mar 2007 14:16:13 GMT
And it happens to work on KF 2  ! Same test with an Hello World bundle.


De : osgi-dev-bounces@www2.osgi.org [mailto:osgi-dev-bounces@www2.osgi.org] De la part de
Envoyé : vendredi 9 mars 2007 14:54
À : OSGi Developer Mail List; felix-dev@incubator.apache.org; OSGi Developer Mail List; osgi-dev-bounces@www2.osgi.org;
Objet : RE: [osgi-dev] Backward compatibility

I am very surprised that you succeeded in running R3 bundles on equinox. I just tried with
the last release of equinox (built on Feb 12th). Maybe I missed a configuration trick ?


De : osgi-dev-bounces@www2.osgi.org [mailto:osgi-dev-bounces@www2.osgi.org] De la part de
ChangWoo Jung
Envoyé : vendredi 9 mars 2007 10:31
À : OSGi Developer Mail List
Cc : felix-dev@incubator.apache.org; OSGi Developer Mail List; osgi-dev-bounces@www2.osgi.org;
Objet : Re: [osgi-dev] Backward compatibility


AFAIK, running R3 bundles on Equinox seems okay. 
I guess you are dealing with OBR deployment side of story. I mean osgi client with obr repository,
I am not the Felix guy though... but have some experience with using OBR2. 
Wouldn't be  possible to regenerate the meta information (repository.xml) at server side using
OBR2 format against existing R3 bundles? 
I guess it will work with bindex which you can get it from osgi site. 

I also found serval things before... 

- OBR2 bundle dislike the situation that if the bundle doesn't have symbolic name. But I guess
it could be easily changed, if there is no symbolic-name then use Bundle-Name instead since
all R3 bundle has. 
-  The packages from org.osgi.framework.system.packages has to be added to SystemPackages's

After that I manage to run existing R3 bundles as well. Actually I used Equinox and OBR repository(OBR2).
But honestly I haven't used Felix as client osgi. 

ChangWoo Jung 
Staff R&D Engineer 
Ubiquitous Computing Laboratory, IBM Corporation 
+82-2-3781-8422 (t/l: 825-8422)s 

"BOTTARO Andre RD-MAPS-GRE" <andre.bottaro@orange-ftgroup.com> 
Sent by: osgi-dev-bounces@www2.osgi.org 

2007-03-09 오후 05:43 
Please respond to
OSGi Developer Mail List <osgi-dev@www2.osgi.org>

<felix-dev@incubator.apache.org>, "OSGi Developer Mail List" <osgi-dev@www2.osgi.org>,
"OSGi Developer Mail List" <osgi-dev@bundles.osgi.org>, <oscar-dev@incubator.apache.org>

[osgi-dev] Backward compatibility	



It happens that more than a year after the 4th public release of OSGi™ 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™ 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 ? 

André _______________________________________________
OSGi Developer Mail List

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