I follow you Guillaume.
In that case, why not just using the features.auto.start property in
org.apache.karaf.features.cfg file and avoid the autostart attribute in the
feature itself.
Like this, the user can manage the autostart feature out of the box and for any
feature.
WDYT ?
On the other hand, as discussed in the past, I think that it could be
interesting to have triggers in features (in before or after installation)
where users can define any Karaf commands.
Regards
JB
On Fri 27/05/11 14:22 , Guillaume Nodet wrote::
On Fri, May 27, 2011 at 14:02, Jean-Baptiste Onofré [email protected]> wrote:
> My comments inline:
>
>>> if I assume that all features descriptor install and start features by
>>> default, to be able to install "my" feature, I need to have Camel features
>>> descriptor installed to know camel-core.
>>> So it means that all Camel features have been installed if it's the default
>>> behavior.
>>>
>>> So we have the same issue: I will have all Camel features installed/started.
>
>>No because you would not drop the camel features file in the deploy
>>folder. It would be referenced using the tag, thus not
>>installed directly.
>
> You are right, but it means that we distinguish feature provided by tag or
> features:addurl / features:install commands from the one provided by a
> features descriptor in the deploy folder or in a KAR.
> I'm agree that it can work, but it means that there will be impact on
> projects. For instance, we should ask to camel to split the features
> descriptor in several files, same in ServiceMix, etc.
Why would you split anything ? I'm thinking if a user wants to install
camel-core, he simply writes its own simple feature which only has a
dependency on camel-core and drop it in the deploy folder. If he then
want to add camel-blueprint, he just has to add one line to that xml.
If we go with flags, it's written in stone and can't easily be changed
(unless we advise users to do a big copy/paste) which is not easily
maintainable.
>
>
>>>
>>> If we don't want to define the behavior on the features itself, as I said
>>> in the Jira comment, we can image to add a property in
>>> etc/org.apache.karaf.features.cfg file:
>>>
>>> features.auto.start = feature1, feature2, feature24/1.1.0
>
>>Isn't that the same than the boot features then ?
>
> The boot features are installed/started at Karaf bootstrap. The features
> descriptors should be present in the local system repo and the URL define in
> the org.apache.karaf.features.cfg configuration.
> The auto.start features property defines the feature automatically
> installed/started when a features descriptor is registered. It's not linked
> to the Karaf bootstrap and could never be used.
Ok, makes sense.
>
> Regards
> JB
>
>
>> I do understand that use case, but adding a flag is kinda abritrary
>> and one may want some features while someone else want another set of
>> features, so adding some flags to the camel descriptor will only
>> benefit a few users.
>> I think to solve that problem, one should write a simple feature
>> descriptor with a single feature and dependencies on what they need.
>> Then they'd just drop that one and have what they want:
>>
>>
>> mvn:org.apahce.camel:....
>>
>> camel-blueprint
>> ....
>>
>>
>>
>> That way, you don't drop camel features descriptor directly, but only
>> the ones you need instead.
>>
>> On Fri, May 27, 2011 at 11:27, Jean-Baptiste Onofré [email protected]> wrote:
>>> Yes, I think we should distinguish the two kinds of features.
>>>
>>> For instance, when adding the camel features descriptor, you have a bunch
>>> of features.
>>>
>>> If it makes to have camel-core, camel-spring and camel-blueprint
>>> automatically installed, I don't think it's the case for camel-stream,
>>> camel-atom, etc as it depends of the user usage.
>>>
>>> I'm afraid that installing all features by default will install a lot of
>>> features for nothing and Karaf will be weight for nothing (especially
>>> regarding ServiceMix :)).
>>>
>>> Regards
>>> JB
>>>
>>> On Fri 27/05/11 11:23 , Guillaume Nodet wrote::
>>>
>>> I agree. The question is does it make sense to have the features
>>> available but not installed ? If not we could just change the
>>> behavior without adding any flags at all.
>>>
>>> On Fri, May 27, 2011 at 11:18, Jean-Baptiste Onofré [email protected]>
>>> wrote:
>>>> Hi Guillaume,
>>>>
>>>> currently, if you drop a features descriptor ino the deploy folder, the
>>>> features are present, but not installed and the bundles are not started.
>>>>
>>>> So the users have to install the features by hand after.
>>>>
>>>> More over, it's the same behavior with a KAR: no features in the KAR are
>>>> installed/started.
>>>>
>>>> On the other hand, it could have sense to have features installed/started
>>>> automatically when adding the features URL.
>>>>
>>>> For instance, adding the Camel features descriptor URL could automatically
>>>> install/start camel-core, camel-spring and camel-blueprint features.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Fri 27/05/11 11:08 , Guillaume Nodet wrote::
>>>>
>>>> What would be the effect ? installing the feature or starting the
>>>> bundles, or both ?
>>>> I think dropping a feature descriptor in the deploy folder should
>>>> automatically install the feature (and start the bundles), I'm not
>>>> sure to see what the benefit of not doing that would be.
>>>>
>>>> On Fri, May 27, 2011 at 10:54, Jean-Baptiste Onofré [email protected]>
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> What do you think about adding an autostart attribute on the features
>>>>> element ?
>>>>>
>>>>> The purpose is to be able to have something like:
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> When an user register a features descriptor (using features:addurl),
>>>>> deploy a KAR containing a features descriptor or drop a features
>>>>> descriptor in the deploy folder, Karaf will try to automatically start
>>>>> the features with autostart flag set to true.
>>>>>
>>>>> It will avoid users to:
>>>>> - start by hand features contained in a KAR: the user can drop the KAR
>>>>> into the deploy folder, but he must connect to Karaf and start the
>>>>> features by hand
>>>>> - start by hand features after an addurl when the user "controls" the
>>>>> features content
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/>>>>
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/>>>
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/>>
>> ------------------------
>> Open Source SOA
>> http://fusesource.com>>
>>
>>
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/>
> ------------------------
> Open Source SOA
> http://fusesource.com>
>
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
