I wonder i we're asking the right question here. We have something we want to "turn on" when a set of n other things are present. We're talking bundles which don't work that way. A more friendly model is DS services with mandatory references. If we say that the n other things are services rather than bundles, and the thing we want to turn on is also a service, then we can use DS to automatically do the detection and wiring and service creation/registration for us.
If we installed a small bundle or two with a feature, that couldn't resolve until some other bundle(s) were also installed, would that be a problem? (or used dynamic import :-(((( ) david jencks On Jul 25, 2012, at 8:13 AM, Scott England-Sullivan wrote: > Do you see the capability feature extension being able to handle the case > where say the web console feature s installed and then you add the event > admin feature, which the pax-web-runtime has an optional dependency on. If > you currently install event admin after web console you get a big nasty > stack trace in the console window. > > I guess what I would hope to avoid is feature soup. It would be very nice > to be able to define all the dependencies and capabilities of SCR under the > SCR feature. Then depending on the features that are installed in > addition to SCR, management and/or web console, those SCR "capabilities" > would be installed. > > Make sense? > > On Wed, Jul 25, 2012 at 3:49 AM, Ioannis Canellos <[email protected]> wrote: > >>> >>> definitely +1; nevertheless I still think we can "marry" Achims >>> proposal together with this capability think; don't you think? >> >> >> Of course, I think that these 2 ideas are complimentary. >> >> -- >> *Ioannis Canellos* >> * >> FuseSource <http://fusesource.com> >> >> ** >> Blog: http://iocanel.blogspot.com >> ** >> Twitter: iocanel >> * >> > > > > -- > -- > Scott England-Sullivan > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://sully6768.blogspot.com > Twitter: sully6768
