I really think that the startup.properties is for infrastructure, bluperint etc. the startup features allows you do "design" your own distro.
On Apr 16, 2011, at 12:42 PM, David Jencks wrote: > 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 >>> >>> >>> >
