śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a):
> Yes, both are possible. > > Maybe keeping all in org.apache.karaf.features.core with a configuration > to use a different deploy/approach is better than a complete new features > bundle. > It’s not a problem to me to refactor what I did. > > Thoughts ? > Personally I'm 65% for keeping single features.core + configuration option and 35% for features.simple ;) regards Grzegorz Grzybek > > Regards > JB > > > Le 19 mai 2021 à 08:01, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit > : > > > > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <j...@nanthrax.net <mailto: > 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* > >
