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