The comparator based on symbolic name is to have something deterministic but doesn’t necessary match. I would like to check If using requirement in a feature would help (I’m afraid it would block the installation but not guarantee the order though).
So, I think it’s worth to evaluate/improve the comparator to have something more "user logic". I will create a Jira and check different scenario. Regards JB > Le 15 oct. 2020 à 17:43, Łukasz Dywicki <l...@code-house.org> a écrit : > > 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 >>>> >>> >>
