Same for me ;) So, let me refactor and remove "my" feature.simple bundle to include in features.core.
I will create the PR soon. Regards JB > Le 19 mai 2021 à 09:21, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit : > > ś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* >> >>
