What you say makes a lot of sense. I was just refering to behavior which I think is there since new resolver come into play. Making it a bit more deterministic is definitely fair (yet expensive in debugging) point to take.
Cheers, Łukasz On 15.10.2020 17:32, Romain Manni-Bucau wrote: > Fact is if features are not installed in reversed graph order it is not > really reliable an you can't install an app and be sure it will work, even > if you sorted manually the bundles. > The ResourceComparator sorts by symbolic names which makes the deployment > deterministic but potentially random from an user perspective > (uncontrollable). > Then the featureservice+resolve use a list of hashmap (or hashset) which > also randomizes the installation. > Guess using at least a reversed dijkstra distance (or tree deepness in some > simple cases) from the feature to sort bundles installation order is worth > it to make it more natural and controlled for end users. > > Hope it makes sense. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le jeu. 15 oct. 2020 à 17:28, Łukasz Dywicki <l...@code-house.org> a écrit : > >> I am not sure if that's feature resolver issue. It is rather related to >> bundle resolver which determines installation order. >> As far I remember from my last debugging session in this area bundles >> are installed in computed "dependency" order. It might be that leaf/1 >> has no direct dependencies on any of its children hence it is installed >> first. >> Note, that I don't know details on how present feature resolution works >> and if its just supplier for graph elements or separate graph computed >> by same algorithm as bundles. >> >> Best, >> Łukasz >> >> >> On 15.10.2020 15:47, Jean-Baptiste Onofre wrote: >>> Hi guys, >>> >>> Romain found an issue on the feature resolver about the features >> ordering. >>> >>> For instance, if we have the following features descriptor: >>> >>> <features name="global"> >>> <feature name="nested1"> >>> <bundle>mvn:foo/nested1/2</bundle> >>> </feature> >>> <feature name="nested21"> >>> <bundle>mvn:foo/nested21/3</bundle> >>> </feature> >>> <feature name="nested2"> >>> <feature>nested21</feature> >>> <bundle>mvn:foo/nested2/2</bundle> >>> </feature> >>> <feature name="leaf"> >>> <feature>nested1</feature> >>> <feature>nested2</feature> >>> <bundle>mvn:foo/leaf/1</bundle> >>> </feature> >>> </features> >>> >>> When installing leaf feature, we expect the following order (for bundles >> installation): >>> 1. foo/nested1/2 bundle (nested1 feature) >>> 2. foo/nested21/3 bundle (nested21 feature) >>> 3. foo/nested2/2 bundle (nested2 feature) >>> 4. foo/leaf/1 bundle (leaf feature) >>> >>> However, the order is not this one. During test, we saw that the order >> is mvn:foo/leaf/1, mvn:foo/nested1/2, mvn:foo/nested21/3, mvn:foo/nested2/2. >>> >>> We can see that the leaf bundle is installed before the bundles from >> inner/transitive features. >>> >>> I would like to investigate this behavior and improve this (I would like >> to check if it’s also the case in previous versions). >>> >>> As the target of Karaf 4.3.0 is this week end, I would take some time to >> check and compare. >>> >>> I will keep you posted. >>> >>> Regards >>> JB >>> >> >
