Hello Guillaume, gnodet wrote: > > There is some work going on in the OSGi Alliance about multiple > frameworks in one JVM (see > http://www.osgi.org/Download/File?url=/download/osgi-core-4.3-early-draft1.pdf > for more informations). This would enable to have a tree of OSGi > frameworks instead of a single instance and would enable controlled > sharing between a framework and its parent. This would enable a > controlled level of isolation and could be used to make sure some > features don't interfere with each other. That's one of the reason > i'm not totally convinced about your proposal. If we'd were to use > nested frameworks, each feature would have its own framework, so that > would not map well to your proposal. > I didn't know that OSGi alliance published new draft so fast.
I am not familar with current draft - but I found that bundle listeners will be also scoped per framework - so when you'll install feature (and budnles) in one other instances will don't know anything about this operation. gnodet wrote: > > The two other things i have in mind for features are: > * give a lifecycle to a feature (start / stop) > * allow more control on the bundles when installed (started level, > start state) > > I agree with you in your proposals: +1 for feature lifecycle +1 allow more control on the bundles when installed gnodet wrote: > > * leverage obr to compute a transitive closure of the feature before > installation > The last one would allow a more loose definition of a feature but just > specifying the list of key bundles and let the features service > determine all the required dependencies and download / install them. I don't know OBR and other stuff so I can't help and vote on this. I can help in first two cases. gnodet wrote: > > FWIW, nested frameworks are not available yet in felix (there's only a > prototype in an equinox branch), so we can't really use those now, but > the other things should be possible to implement now. In particular, > the use of OBR should now be possible since the new release as some > acceptable performances. I think we can leave 4.3 and it's features and make Karaf good base to work with OSGi 4.2. >From my side groving osgi complexity it's bad idea - I love KISS principle and in my idea OSGi 4.2 is good example of simple and powerful environment. We should wait until 4.3 will be in final stage to get them into Karaf. Best regards, Lukasz Dywicki -- View this message in context: http://old.nabble.com/Karaf-features-improvements-tp28622180p28631675.html Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
