To try to help on the different points you mention: 1.a prerequisite is good when you have two stagings - order to respect to install a full feature - so it is a very rare and limited case (in my app I have 5 for ex) 1.b requirements doesn't help with the order (until a framework extension), just with "start" which fails so you can still have a bundle starting and not having some dependency so at the end order is still required 2. the comparator is not sufficient by itself, all the Set and Map are not sorted in karaf featureservice/felix resolver so they also break the order
So at the end I think the order is a requirement of the features - but still amazed it didnt pop up before. 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 ven. 16 oct. 2020 à 05:59, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > 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 > >>>> > >>> > >> > >
