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