śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a):
> Hi, > > Actually, it’s a complete separated bundle. > > So, in the Karaf standard distribution, you will have > org.apache.karaf.features.core in etc/startup.properties: that’s the > regular/current one with the resolver. > > Alternatively, you will have another distribution (I have to think about > the name), where you will have org.apache.karaf.features.simple in > etc/startup.properties: it doesn’t use the resolver, just loading the > features model and executing what’s in there. > Another, different, "non-canonical" distribution is fine ;) > > Another possible approach is a configuration in > etc/org.apache.karaf.features.cfg where we use a different/pluggable > deployer. > This can still be done in standard, "canonical" distro, but as commented-out configuration option. regards Grzegorz Grzybek > > Thoughts ? > > Regards > JB > > > Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit > : > > > > Hello > > > > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <j...@nanthrax.net> > napisał(a): > > > >> 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. > >> > > > > Will it be configurable? I know about refresh problems - but the resolver > > did a good job showing you what's wrong with the set of features/bundles > > you're installing. > > Do you plan to switch to resolverless features service in micro release > of > > Karaf? Or will it be Karaf 4.4 / 5? > > > > regards > > Grzegorz Grzybek > > > > > >> > >> 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* > >>>>> > >>> > >> > >> > >
