so that proposal is about adding a new concept of Priority in the Component descriptor interface. This priority would have different usages:
- if 2 components have same hint and role, the one with most priority would override the other one (this would solve: [XCOMMONS-1814] Component with higher priority is not taking precedence when deployed as an extension - XWiki.org JIRA). This would need to be backward compatible with the priorities defined in components.txt
- when getting list or map of components through the API, those list and maps would be automatically ordered by priority: this would allow different UC, like some transformation happening before others, or some listener being called before others
For defining the priority in Java components there would be different mechanism:
- for backward compatibility reason, it should still be possible to define it through components.txt (which would have the priority over other mechanisms)
- it should be possible to also define the priority when defining a new component as a Java class, so I propose to add the priority field in the
- I don’t know much the definition of components through xobject, but we should also find a way to define the priority there (probably through a new property)
For backward compatibility reason, all components which do not define their priority would have a same priority value (probably defined to
1000 as it’s the actual default value in components.txt if I’m correct).
Now I also propose that contrarily to what we have now, we do define a specific ordering of the components when they all share the same priority, to stop relying on randomness: so I propose that we use lexicographic sorting based on the fully qualified name of the components for that.