In orded to fix #82 , and allow for a standard way to name scenarios, in this pull request i made the following:
Used @JacksonInject annotation to inject the owner module into the scenario constructor, leaving the need for a setter method afterwards (Scenario was the only case) and allowing the module to be declared final for all inputs. This also allows module information to be accessed in the scenario constructor
Unified the scenario name definition, by eliminating the name field in scenario JSON files and just naming it automatically after the module which creates it (followed by .scenario)
So, to be clear, with the new changes, a scenario definition would only be the event list, for example:
In orded to fix #82 , and allow for a standard way to name scenarios, in this pull request i made the following:
@JacksonInject
annotation to inject the owner module into the scenario constructor, leaving the need for a setter method afterwards (Scenario was the only case) and allowing the module to be declared final for all inputs. This also allows module information to be accessed in the scenario constructorname
field in scenario JSON files and just naming it automatically after the module which creates it (followed by.scenario
)So, to be clear, with the new changes, a scenario definition would only be the event list, for example:
I believe naming the module in the configuration path (which also has the path to the scenario file) and the file itself is clear enough