Reasoning

Currently we are maintaining two start scripts for Run, which are about 90 lines each. The scripts contain rather verbose logic to handle the 5 parameters that can be passed to Run. Currently, we have --production, --webapps, --rest, --example and --swaggerui. The logic needs to be implemented in the .sh and in the .bat script.

If a user wants to supply their own arguments, e.g. Spring CLI parameters, they need to edit the start script as the script drops all but the 5 arguments.

All other configuration of Run is set in the .yml file.

Advantages of current solution:

• already works
• if an option is not set, the respective classes are not on the classpath, reducing potential security risks from these classes.

Disadvantages of current solution

• There are two places to configure Run, the command line and the properties in the .yml file. The invoice example even needs to be configured in both. This could be a bit confusing for the user. Ideally, the command line options would also be configurable via the .yml file. 
• It is hard for users to supply their own arguments, such as port number, debug options etc. via the cli ,if they want to. Additional options need to be added in the script on the last line which is quite long.

Hints:

Ideally, these parameters would be parsed in Java, this would avoid large parts of the redundant implementation and make it easier to test.

Additionally, these options could be configured via the application properties yaml file (default.yml and production.yml) using springs @ConditionalOnProperty mechanism. For example, the webapps can already be enabled/disabled via these files.

camunda.bpm:
  admin-user:
    id: demo
    password: demo
  webapp.enabled: false
[...]

In this case the property can also be passed via command line, like so:

 --camunda.bpm.webapp.enabled=false

Implementing the options as spring properties would could clear up whats on by default. Additionally, there can be short names . This would keep all configuration in one place. 

The disadvantage is that this would likely keep the classes on the classpath.