Hi JB, Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-) The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
I think you are saying: -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already. and, looking more closely at the add-features-to-repo mojo I see there's a <features> configuration element that lets you specify features to install the bundles for. I'm going to add that capability to the karaf-assembly packaging. There's another difference of style to resolve. I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level. For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties. On the other hand you can't uninstall this feature so easily. Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties? many thanks david jencks On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote: > Hi David, > > I'm not sure to follow you. bootFeatures property defines which features are > started at Karaf bootstrap time. It allows user to start a fresh Karaf > instance with a set of Karaf features loaded and installed. > > For instance, in ServiceMix, we have: > - nmr feature as boot feature and we ship all required jar (using > features-add-to-repo goal) in the system OBR > - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot > features set. As we consider this kind of features as optional, we don't ship > the features jar in the system OBR > > Regards > JB > > On 04/16/2011 08:32 AM, David Jencks wrote: >> I am wondering why we have boot features in trunk. In particular I think >> there is an inconsistency around the management feature which is in the >> minimal boot feature list and whose jars are in the minimal server assembly. >> On the other hand the ssh full boot feature doesn't have all its jars in >> the full server. >> >> If a boot feature doesn't already have all its jars in the server, won't >> this require internet access on initial startup? >> >> If all the jars for a boot feature are already installed in the server, why >> call it a boot feature, why not just start it with the rest of the jars? >> For this question I may be biased by looking at the packaging based >> assemblies where the startup.properties is constructed from the features >> that are installed into the server, so it is at least as east to configure >> the assembly to just include the jars as to configure a boot feature. >> >> Am I missing something? >> >> thanks >> david jencks >> >> >>
