fabianbuch
commented
12 years ago Comment of David Linsin: What's the problem? When you configure an instance (a set of modules), e.g. SampleApp, there can be multiple configuration files (@local.properties@/@production.properties@). Each module can bring its own config and due to none deterministic loading of modules in a WAR, you have no control of which configuration file is loaded first. That means you cannot define a "master" config in your instance, which overrides module configs.
How to solve the problem?
By convention, when you configure an instance, e.g. SampleApp, there's only one configuration file (@local.properties@/@production.properties@) allowed for all modules, encompassing this instance.
- SampleApp (@local.properties@/@production.properties@) * CalendarModule (@immutable config@) * AddressModule (@immutable config@) \ CoreModule (@ immutable config@)
All modules can define a module-local configuration, which is immutable and cannot be overwritten by the main configuration of an instance.
How do you develop a single module?
You define your own @local.properties@, which are not checked in, and are only valid for your own development.
Currently the installer creates 100 dummy users for development purposes. We should extract this behaviour into a class only available in development.