Hi, Regarding recent comments from users and lot of refresh issues/questions we have in the past, I moved forward with a new simple features service that doesn’t use the resolver. It basically reads the features repo definition and just install what’s define in there statically.
I will prepare a distribution using it by default. I will share some details soon. Regards JB > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > > Hi, > > It doesn’t really break, it just don’t use it. > > It’s up to you to install all feature/bundle requirements. > > Regards > JB > >> Le 11 janv. 2021 à 21:09, Markus Rathgeb <maggu2...@gmail.com> a écrit : >> >> Hi, >> >>> - ignore requirement/capability (no resolver) >> >> did I get it right that this breaks the dependency=true feature that >> installs bundles / features only if a requirement is not fullfilled yet? >> >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault < >> patriquelega...@gmail.com>: >> >>> Same here, >>> >>> This is behaviour that has been expected for some time now, reversing it >>> could cause damage to systems that upgrade to the latest Karaf. I would >>> make it something that users opt into vs having to opt-out of. >>> >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel....@empirica.io.invalid> >>> wrote: >>> >>>> Hi, >>>> >>>> It looks like some kind of backward incompatible change introduced within >>>> patch version change. I personally would like to keep auto refresh "on" >>> by >>>> default as this is expected/desired behavior for me. >>>> >>>> Regards >>>> >>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <j...@nanthrax.net> >>> napisał(a): >>>> >>>>> Hi everyone, >>>>> >>>>> We got several user feedback, complaining about unexpected and cascaded >>>>> (unrelated) refresh while installing features. >>>>> >>>>> As reminder, a refresh can happen when: >>>>> - bundle A imports package foo:1 and a bundle provides newer foo >>> package >>>>> version. In that case, the features service will refresh A to use the >>>>> newest package version. >>>>> - bundle A has an optional import to package foo and a bundle provides >>>>> this package. In that case, the features service will refresh A to >>>> actually >>>>> use the import as it’s a "resolved" optional. >>>>> - bundle A is wired to bundle B (from a package perspective or >>>>> requirement) and B is refreshed. In that case, the features service >>> will >>>>> refresh A as B is itself refreshed (for the previous reasons for >>>> instance). >>>>> This can cause "cascading" refresh. >>>>> >>>>> A refresh means that a bundle can be restarted (if the bundle contains >>> an >>>>> activator or similar (DS component, blueprint bundle)). >>>>> >>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to >>>>> introduce a new property autoRefresh in >>> etc/org.apache.karaf.features.cfg >>>>> to disable the auto refresh by the features service (and let the user >>>>> decides when he wants to trigger refresh with bundle:refresh command >>> for >>>>> instance). >>>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false >>> on >>>>> 4.3.x. >>>>> >>>>> Thoughts ? >>>>> >>>>> On the other hand (and to prepare the "path" to Karaf5), I have >>> created a >>>>> new "simple features service" (PR will be open soon) that: >>>>> >>>>> - just take the features definition in order (ignoring start level) >>>>> - ignore requirement/capability (no resolver) >>>>> - no auto refresh >>>>> >>>>> Basically, if you have the following feature definition: >>>>> >>>>> <feature name="foo" version="1.0"> >>>>> <feature>bar</feature> >>>>> <bundle>A</bundle> >>>>> <bundle>B</bundle> >>>>> </feature> >>>>> >>>>> The features service will fully install/start bar feature first, then >>>>> bundle A, then bundle B. >>>>> To use this "simple features services, you just have to replace >>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple >>> bundle >>>>> in etc/startup.properties (or custom distribution). >>>>> >>>>> It’s similar to the Karaf 5 extension behavior (I will share complete >>>>> details about Karaf 5 and its concepts (module, extension, …) very >>> soon, >>>>> but that’s another thread ;)). >>>>> >>>>> The big advantages of this approach is: >>>>> - predictable/deterministic provisioning (if it works fine, it works >>>> again) >>>>> - faster deployment (I estimated the gain to about 70%) >>>>> >>>>> Thoughts ? >>>>> >>>>> If you agree, I will move forward on both tasks. >>>>> >>>>> Thanks, >>>>> Regards >>>>> JB >>>>> >>>> >>>> >>>> -- >>>> Daniel Łaś >>>> CTO at Empirica S.A. >>>> +48 695 616181 >>>> >>> >>> >>> -- >>> *Patrique Legault* >>> >
