On Fri, May 27, 2011 at 14:35, Jean-Baptiste Onofré <[email protected]> wrote: > > > > 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.
Sounds good to me. Better than using flags actually. But that still means that dropping a kar won't actually install anything. It sounds a bit confusing to me and I'm not sure to actually see any value in doing that. It should be similar than other artifacts imho: when you drop something in the deploy folder, you kinda expect it to be installed and started (bundles, wars, jbi sas, etc...). > 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. > I fully support this idea. > 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 > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
