Ok, I will write code similar to feature state management (verify blueprint/spring context state) and bundle monitoring based od feature sets. I can provide patch for these things.
Regards, Lukasz gnodet wrote: > > On Fri, May 21, 2010 at 11:42, Lukasz Dywicki <[email protected]> wrote: >> >> 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. >> > > Well, the idea would be that a feature would create a new nested > framework, so all features would be visible from the top level. > >> >> >> 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. > > OBR is a repository containing OSGi metadata. It would be used to > compute the required dependencies. > >> >> >> 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. >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > -- View this message in context: http://old.nabble.com/Karaf-features-improvements-tp28622180p28654869.html Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
