Yeah, that's actually the only case where the bundle is is important afaik.
However, when using Karaf 4 feature service, things are slightly different : let's say you have 2 features, each feature containing a bundle which export the same package but in different version. If a single bundle can be used (that would mean they are flagged as dependencies), the feature service will only install one bundle. At the end, if bundles flagged as dependencies won't be used in the wiring, they won't be installed at all. 2016-08-26 15:21 GMT+02:00 James Carman <ja...@carmanconsulting.com>: > The bundle id is important, especially when trying to resolve the same > packages from multiple bundles, because the lower bundle id is supposed to > be chosen when there are multiple options for the same dependency range. > That's what I'm trying to control mostly. > > > On Fri, Aug 26, 2016 at 8:59 AM Guillaume Nodet <gno...@apache.org> wrote: > >> The installation order is not really relevent, what is important is the >> startup order. >> Once the list of bundles has been computed, the features service does the >> following: >> #1: stop bundles that needs to be updated or uninstalled in order >> #2: uninstall needed bundles >> #3: update regions >> #4: update bundles >> #5: install bundles >> #6: save state >> #7: install configuration >> #8: refresh bundles >> #9: start bundles in order >> #10: send events >> >> For point #9, bundles are split in multiple sets according to their their >> order, and in each set, they are sorted in a way that will try to ensure >> the bundles are correctly and fully resolved (see FELIX-2949, because Felix >> resolver is not greedy). >> >> What's the problem you're trying to solve exactly ? >> >> 2016-08-26 13:56 GMT+02:00 James Carman <ja...@carmanconsulting.com>: >> >>> Wonderful. Something needs to be done about that, then. >>> >>> On Fri, Aug 26, 2016 at 7:55 AM Guillaume Nodet <gno...@apache.org> >>> wrote: >>> >>>> No, that's true for 2.x and 3.x. >>>> 4.x converts the feature list to a list of requirements, builds >>>> resources, launch the OSGi resolver, check the current state and apply the >>>> difference. >>>> >>>> >>>> 2016-08-26 13:52 GMT+02:00 James Carman <ja...@carmanconsulting.com>: >>>> >>>>> It iterates through what you hand it, doesn't it? >>>>> >>>>> On Fri, Aug 26, 2016 at 7:50 AM Guillaume Nodet <gno...@apache.org> >>>>> wrote: >>>>> >>>>>> Yeah, BootFeaturesInstaller keeps the order and pass a LinkedHashSet >>>>>> to the FeaturesServiceImpl, but that one does not care about the order by >>>>>> design. >>>>>> >>>>>> >>>>>> 2016-08-26 13:46 GMT+02:00 James Carman <ja...@carmanconsulting.com>: >>>>>> >>>>>>> We change the code to use a list ordered set, so the order is >>>>>>> preserved. It has been applied to all branches >>>>>>> >>>>>>> On Fri, Aug 26, 2016 at 7:45 AM Guillaume Nodet <gno...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Afaik karaf-4642 only really applies to 3.x unless you use stages >>>>>>>> with one feature per stage. >>>>>>>> Features in a single stage are installed all at once, so the order >>>>>>>> is lost. >>>>>>>> A simple proof is to look at the list of bundles installed with a >>>>>>>> bare karaf 4.x install : the order of the installed bundles is >>>>>>>> unrelated to >>>>>>>> the order of the features listed in the configuration, that's because a >>>>>>>> single stage is used. >>>>>>>> >>>>>>>> 2016-08-26 13:14 GMT+02:00 James Carman <ja...@carmanconsulting.com >>>>>>>> >: >>>>>>>> >>>>>>>>> That's not entirely true. The featuresBoot ordering has been fixed >>>>>>>>> by >>>>>>>>> karaf-4642. >>>>>>>>> >>>>>>>>> On Fri, Aug 26, 2016 at 3:42 AM Guillaume Nodet <gno...@apache.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The only way to influence the start order of bundles is to >>>>>>>>>> specify the start level on the feature or on the feature's bundles >>>>>>>>>> using >>>>>>>>>> the start-level attribute (see https://github.com/apache/ >>>>>>>>>> karaf/blob/karaf-4.0.x/assemblies/features/standard/ >>>>>>>>>> src/main/feature/feature.xml for some examples). >>>>>>>>>> >>>>>>>>>> In Karaf 4.x, the features are resolved and installed in a single >>>>>>>>>> pass, so the order is lost. >>>>>>>>>> >>>>>>>>>> 2016-08-26 4:58 GMT+02:00 oski_bear <dariusham...@hotmail.com>: >>>>>>>>>> >>>>>>>>>>> Hello, I'm a long-time user of Karaf 2.4.0 trying to migrate my >>>>>>>>>>> application >>>>>>>>>>> to Karaf 4.0.5. One thing I've noticed is that in this new >>>>>>>>>>> version of Karaf >>>>>>>>>>> there doesn't seem to be any way to specify the order in which >>>>>>>>>>> bundles are >>>>>>>>>>> ordered. >>>>>>>>>>> >>>>>>>>>>> For example, if I specify "bootFeatures" in the >>>>>>>>>>> karaf-maven-plugin they >>>>>>>>>>> don't start in the order that I list them. Additionally, when I >>>>>>>>>>> create my >>>>>>>>>>> own features they don't load in the order they are written and >>>>>>>>>>> the container >>>>>>>>>>> does not seem to respect the start levels. >>>>>>>>>>> >>>>>>>>>>> Am I missing something here? Is there a way to enforce a certain >>>>>>>>>>> order in >>>>>>>>>>> the boot features with the karaf-maven-plugin? Is there a way to >>>>>>>>>>> force an >>>>>>>>>>> order when defining a feature? >>>>>>>>>>> >>>>>>>>>>> Please help me understand. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> View this message in context: http://karaf.922171.n3.nabble. >>>>>>>>>>> com/Karaf-4-0-5-bundle-startup-order-tp4047689.html >>>>>>>>>>> Sent from the Karaf - User mailing list archive at Nabble.com. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------ >>>>>>>>>> Guillaume Nodet >>>>>>>>>> ------------------------ >>>>>>>>>> Red Hat, Open Source Integration >>>>>>>>>> >>>>>>>>>> Email: gno...@redhat.com >>>>>>>>>> Web: http://fusesource.com >>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------ >>>>>>>> Guillaume Nodet >>>>>>>> ------------------------ >>>>>>>> Red Hat, Open Source Integration >>>>>>>> >>>>>>>> Email: gno...@redhat.com >>>>>>>> Web: http://fusesource.com >>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Red Hat, Open Source Integration >>>>>> >>>>>> Email: gno...@redhat.com >>>>>> Web: http://fusesource.com >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Red Hat, Open Source Integration >>>> >>>> Email: gno...@redhat.com >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>>> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: gno...@redhat.com >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
