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* >
