Module
Related Doc:
package akkamo
Each Akkamo module must override this method in order to exactly define its module dependencies, otherwise there will be risk that it will not be initialized and run in proper order.
Each Akkamo module must override this method in order to exactly define its module
dependencies, otherwise there will be risk that it will not be initialized and run in proper
order. Fox example if this module depends on modules ModuleA and ModuleB, then the
overridden method should look like:
override def dependencies(dependencies: Dependency): Dependency = dependencies.&&[ModuleA].&&[ModuleB]ś
instance of eu.akkamo.Dependency
chained module dependencies
Default implementation of toString of Akkamo module returns the module name itself
(simple class name).
Default implementation of toString of Akkamo module returns the module name itself
(simple class name).
simple class name of the Akkamo module
Trait representing the Akkamo module, i.e. independent application unit, with possible dependencies on another modules, providing own functionality to other modules. The main goal is to allow writing applications as a set of modules, loosely coupled each other, allowing to easily add new functionality to existing application (or remove it), or to prepare several different application build profiles, with different functionality (modules) included.
Each Akkamo module has its own lifecycle, with following stages: init stage (Initializable trait), run stage (Runnable trait) and dispose stage (Disposable trait). In order to execute desired module logic in selected stage, corresponding trait must be mixed in.
Disposable
Runnable
Initializable