Hi JB, picking up your two ideas,
for 1 I'd rather would expect something like features:addUrl -s like with the osgi:install that it should start all features within the features url this way we are more consistent and I think it gives the user the needed control. for 2 I agree since is actually the behavior I would have expected anyways :-) regards, Achim 2011/5/31 Jean-Baptiste Onofré <[email protected]>: > Hi Christian, > > I'm fully agree with you and it's my first concern when you read my previous > e-mail of the thread. > > I prefer: > 1/ add a autostart property in the etc/org.apache.karaf.features.cfg file to > features installed from the command line. It allow people to automatically > start the features that he wants. > 2/ enhance the deployer (kar and features) to automatically start the > features dropped in the deploy folder > > Regards > JB > > On 05/30/2011 08:05 PM, Christian Schneider wrote: >> >> Hi JB, >> >> I don´t think autostart makes sense as a default. For example take the >> camel feature file. You would probably never want to start all the >> features. Blacklisting all that should not be started also seems like a >> bad idea as in the camel case that would be just too many. >> >> I like the current way it works. features:addurl only installs the file >> and in a scond step you start the features you need. An option on addUrl >> could start all the features in the file if this is wanted. >> >> For features dropped into the deploy dir the dir should give the >> default. So if the default is to start bundles dropped into that dir >> then features should also be started. Kars should then behave in the >> same way. >> >> Christian >> >> >> Am 30.05.2011 07:44, schrieb Jean-Baptiste Onofré: >>> >>> Hi Mike, >>> >>> it's another point of view. We can mix the Guillaume and your remarks: >>> >>> 1/ avoid to include an autostart attribute in the features descriptor >>> and prefer the usage of features.blacklist property in >>> etc/org.apache.karaf.features.cfg file. This property defines the >>> features (feature name or feature name/version separated by a comma) >>> which won't be started/installed automatically >>> 2/ by default, install/start all features contained in a features >>> descriptor. >>> >>> We just need to be careful with large features descriptor such as the >>> Camel one. The features.blacklist property should support LDAP filter >>> format to define the blacklisted features (for instance >>> (&(!name=camel-core)(name=camel-*) to start/install only the >>> camel-core feature). WDYT ? >>> >>> Regards >>> JB >>> >>> On 05/29/2011 10:36 PM, mikevan wrote: >>>> >>>> -1 (non-binding) >>>> >>>> It has always appeared strange to me that features:addUrl didn't work >>>> the >>>> same way as dropping a features.xml into the deploy directory. >>>> >>>> In practice, dropping a features.xml file into the deploy directory >>>> currently deploys all of the features listed in that file. The rub >>>> appears >>>> to be that this is not the default behaviour when using >>>> features:addUrl to >>>> add a features repository. I like the idea of this when using the >>>> features:addUrl command, however my question is what would this do to >>>> the >>>> default behaviour of the deploy directory? Would we have an "autostart= >>>> false" for features we dont' want to start when adding a features >>>> repository >>>> via the deploy directory? >>>> >>>> Instead, I propose the following: >>>> 1) change the features:addUrl behaviour to match the behaviour we see >>>> when >>>> adding a features file to the deploy directory, basically this would >>>> remove >>>> the need for an autostart=true capability as all features would be >>>> started >>>> automatically unless otherwise noted, and >>>> 2) add an "autostart=false" attribute to the features.xml xsd that would >>>> keep the feature from being deployed. >>>> >>>> >>>> >>>> jb-3 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: >>>>> >>>>> <feature name="myfeature" version="1.0-SNAPSHOT" autostart="true"> >>>>> ... >>>>> </feature> >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> ----- >>>> Mike Van (aka karafman) >>>> Karaf Team (Contributor) >>>> -- >>>> View this message in context: >>>> >>>> http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-tp2992236p2999943.html >>>> >>>> Sent from the Karaf - Dev mailing list archive at Nabble.com. >>> >> > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
