This patch is really useful to have and it has helped me think about where we can go with this.
A possible design is to have the config file outside the WAR file, in a well-known standard place (or series of places and play the game of "hunt the config"). If the config is in the WAR file, the user has to edit or make the WAR file in some way so from an easy of use point of view, a single war and a well known place for the config might be easier for users who then do not need to have detaled knowledge of WAR file builing.
This works with having TDB databases in a common place as well, which will be needed when adding the ability to create/delete databases in a running server, also control security. Then there is a usage where there is no user written config file (many people seem to run from command currrentyl anyway) - and everything is UI controlled.
The config file does not go away - the other use case of a planned, automated depolyment means a config file to easily set up a server remotely is needed.
Security - Apache Shiro looks good for this but we don't want to just assume use of that. We'll need to design so Fuseki can work within any reasonable security fremwork from container provided to enterprise stuff.
servelts, config parsing,
turn the control panel into a proper system admin console.
(no need to make separate but depending on technology used it might be easier)
current distribution: adds Jetty, packaging as a zip, scripts
packaging in war format
(I am not a fan of too many maven modules but in practice its going to be easier to have several rather than build variations by classifier out of a common code pool).