-
Type: Improvement
-
Status: Resolved
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: explorer-20.0.0
-
Component/s: Explorer
-
Epic Link:
-
Team:AT
-
Sprint:nxAT 11.1.24, nxAT 11.1.25, nxAT 11.1.26
-
Story Points:5
After changes for NXP-29489, it appears that registration order set on components is not the relevant one.
Components are registered in a given order, but it is not taken into account correctly by explorer (should be asking for resolved components to the component manager, not all components).
Linking to NXP-28948 as pending components, components in error, etc.. are currently taken into account while they would not be if we considered only resolved components.
The relevant orders might actually be more complex to represent, as a given component can register its extensions "lazily" (waiting for target extension point to be present, or a requirement to be resolved).
Current sort on registrations, taking Component#getApplicationStartedOrder, is handled only after components activation (after registration of contributions), and before calling the components #start method.
Note: the component manager also uses watches, for loggin purposes: it would be useful to extract them for rendering and make it possible to notice deployment latency issues.
- depends on
-
NXP-29641 Fix component manager events on pending registrations
- Resolved
-
NXP-28950 Compute bundle and component deployment order in Explorer
- Resolved
-
NXP-29489 Replace bundle deployment order by component min and max registration order in explorer
- Resolved
-
NXP-29373 Add documentation on components and bundles requirements and order
- Resolved
- is related to
-
NXP-29580 Rework descriptor mechanism
- Resolved
-
NXP-29571 Allow registering runtime component listeners early
- Resolved
- is required by
-
NXP-29371 Automate explorer reference export
- Resolved
-
NXP-29561 Provide plotly rendering of explorer default exports
- Resolved
- Is referenced in