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 > <repository/> 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
