OK, another feature proposal for 3.0: I've the following "problem" with the OpenEngSB project right now. We have different features where some are optional, but if they are defined they could also start in parallel. E.g. assume you have feature A and feature B. Feature A requires some time to come up since it requires some time to get all blueprint services wired, BUT feature B does not need to wait till feature A is finished but could rather startup with feature A (as if they're defined in the same feature).
I can think of two solutions for the problem 1) Define parallel startup in features.cfg. In Archlinux you have a Daemons array defined saying which services to start during the boot which looks something like: DAEMONS=(syslog-ng netfs crond dbus !network wicd @acpid @cups @ntpdate @mpd) This means now: first start syslo.. then netfs, then crond (one after the other, similar to our feature file), but you don't have to wait for acpid, cups, ntpdate to wait, start them up and go ahead (thats what the @means). I can think of the same for Karaf: A,@B which could mean: start feature A and feature B like they where the same feature 2) A different solution could be to add a new tag to the features.xml listing the features with which a feature could be started in parallel ---> Feature B could contain: <couldBeStartedTogetherWith><feature version...>A</feature><feature version...>OTHER_FEATURE</feature></couldBeStartedTogetherWith> ------------ I think it may be good to support borth options since the feature developer should now best with which features his feature could start in parallel, BUT the feature developer can not imagine each possible feature which could be started in parallel with his feature. So, WDYT? :) Kind regards, Andreas
