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:
<features>
<repository>mvn:org.apahce.camel:....</repository>
<feature name="what-i-need">
<feature>camel-blueprint</feature>
....
</feature>
</features>
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
