Hi JB, a +1 from me, this sounds the best way.
regards, Achim 2011/6/1 Jean-Baptiste Onofré <[email protected]>: > Yes, features:install with regexp could do the stuff. > > But my purpose is to define a policy global to the Karaf instance: the users > will forget to add options. > > So I propose: > - add the -s option to features:addurl command, supporting LDAP filter > - add regex support in features:install. I started to enhance the > bundle/feature commands in that way (KARAF-325, KARAF-452) > - add features.autostart property in etc/org.apache.karaf.features.cfg file > to define a global policy > > Regarding the kar, we agreed that dropping the kar into the deploy folder > should install/start all features contained in the Kar. > I also propose to add a kar:install specific command to manipulate Kar > archives (I already raised a Jira for that in the past KARAF-460). > > Regards > JB > > On 06/01/2011 08:27 AM, Christian Schneider wrote: >> >> I understand what you mean. Still the same could be achieved by first >> calling the the feature:addurl and then feature:install. The -s option >> can be handy of course when you want to start many features at once. >> Btw. we could alternatively support regular expressions in >> features:install. >> >> How about the .kar case? You can not use an option when dropping a file >> in the deploy dir. So I guess in this case we can only install all >> features. Is that correct? >> >> Christian >> >> >> Am 01.06.2011 07:18, schrieb Jean-Baptiste Onofré: >>> >>> Hi Christian, >>> >>> Starting with the hypothesis that your features descriptor looks like: >>> >>> <features> >>> >>> <feature name="my" version="1.0"> >>> <feature>camel</feature> >>> <feature>camel-stream</feature> >>> <bundle>mvn:my/my-bundle/1.0</bundle> >>> </feature> >>> >>> <feature name="my.optional" version="1.0"> >>> <feature>my</feature> >>> <bundle>mvn:my/my-optional/1.0</bundle> >>> </feature> >>> >>> </features> >>> >>> you could expect that your "my" feature will be automatically >>> installed/started as soon as you register the URL, but not my.optional. >>> >>> The purpose of the -s option with the LDAP filter is to be able to >>> automatically start a set of features. >>> >>> Regards >>> JB >>> >>> On 05/31/2011 10:16 PM, Christian Schneider wrote: >>>> >>>> Sounds better to me than other options but I wonder if we really need >>>> this at all. >>>> >>>> When I deploy a camel app then I create a feature file for it with one >>>> feature that that references all camel features it needs. So I would >>>> intall the camel feature file without starting any features. Then I >>>> would install the feature file of my app and there all of the features >>>> in the file (typically only one) could be auto started. So in my >>>> practice I never needed to start some features. I always either wanted >>>> to start all or no features. >>>> >>>> Christian >>>> >>>> >>>> Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré: >>>>> >>>>> Good idea Achim, >>>>> >>>>> +1 to provide -s option with LDAP filter support. >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 05/31/2011 09:33 AM, Achim Nierbeck wrote: >>>>>> >>>>>> Hi JB, >>>>>> >>>>>> I understand your concern, especially with the camel features file >>>>>> which is the biggest I know of right now :-) >>>>>> Never the less I think this should be a straight forward approach and >>>>>> transparent for the user. So if we decide >>>>>> to constrain this behavior it should be done through the command. >>>>>> So something like >>>>>> >>>>>> features:addUrl -s (ldap filter) >>>>>> >>>>>> - to only start the features matching and >>>>>> >>>>>> features:addUrl -s >>>>>> >>>>>> - to start all features inside the features file >>>>>> >>>>>> I think this gives the user the right amount of control while doing >>>>>> exactly what he wants. >>>>>> If we think of a external file to alter, it won't be as transparent. >>>> >>> >> > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
