Currently the only dependency that we have is that VisionAspect threads depend on a thread being active with the VisionMasterAspect. But for the future we may even more such dependencies.

Additionally currently there is no easy way to fulfill the dependency. It can only be detected that the dependency is not met and the plugin cannot be loaded. There is no way to load the plugin that could fulfill this dependency.

The idea is to extend Plugin by a requires() method that returns a list of plugin names. Then a policy can decide if loading a plugin where dependencies cannot be fulfilled should fail or if the plugin loaded should try to fulfill the dependencies by loading these plugins.

An example are vision apps, like fvretriever. You could then load fvretriever and it would have fvbase as a dependency. The plugin loader could see this and load fvbase before fvretriever to fulfill the dependency. If this is not possible (or for example auto dependency resolution is disabled in the config) the loading of fvretriever would fail.

The aspect dependencies remain necessary. For example fvretriever could not name fvbase as a requirement. Loading the plugin would be attempted and without the aspect dependencies the loading would succeed, but running would not meet the guarantees of aspects and the application were likely to crash.

This idea does assume that for most plugins it's easy to define the dependencies and that in general there will be only one plugin providing the functionality, for example the vision master. If that changes it may be necessary to have a more flexible dependency description, but for the beginning the simple solution should suffice.