What I am proposing is the equivalent of using the current deploy tool, and then adding the module's configId to the server command line next time you start it -- which is what you can do today. I don't see how that makes the situation worse.
No, you were proposing having the deployment tool hack the internal file used by a specific GBean. I object to that as it relies on implementation detail.
You seem to be sugesting that the deploy tool should only work fully when the server is running, and if the server is not running, then you need to use a different command to start the server and deploy at the same time. Is that right?
No, I was proposing adding the command line option to the server that added a configId to the list retrieved from the last-known-configs GBean. This is a portable way of achieving what you were trying to do above. It is also simply "start" and not "deploy"
You can install(distribute) offline to your heart's content but I don't want the user fooled into thinking their app is startable when it isn't. The "deploy" tool (as in distribute/start) can *only* work with a running server as that is the only way to tell if the application is startable.
I think the typical usage will be:
start server repeat write code build (with distribute/start to online server) test until app works or it's time to go home
rather than
repeat write code build (with 'deploy' to offline server) start server check logs for errors test stop server until app works or it's time to go home
We should make the first simple and reliable.
-- Jeremy
