Well, I think it may promote confusion, but there are now 3 options for
features in features repositories of maven runtime scope:
startupFeatures. The bundles in these features will get installed into system
and listed in startup.properties
bootFeatures: The bundles in these features will get installed into local-repo
and the feature names added to bootFeatures in the features cfg file
installedFeatures: The bundles in these features will get installed into
local-repo.
For instance,
<configuration>
<startupFeatures>
<feature>ssh</feature>
<feature>config</feature>
<feature>management</feature>
</startupFeatures>
</configuration>
Note that except for startupFeatures the bundles are installed into local-repo.
I think system should only have bundles started from startup.properties in it.
thoughts?
thanks
david jencks
On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
> For me it'd be the same logic as not "starting" everything from tomcats
> endorsed lib and
> just deploying WAR file, perhaps a little convoluted comparison, but the
> features additions, adding
> things and keeping "application" vs. features does make it simpler to manage
> as your features and deployments grow.
>
>
> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>
>> If the same bundles all get started when you start the server, what is the
>> difference? I think you've "designed" the server you want by including the
>> bundles and indicating that you want them started at server startup. How is
>> it different whether the bundles are started from startup.properties or the
>> feature service looking at boot features?
>>
>> thanks
>> david jencks
>>
>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
