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