Jeremy, What is your feeling on the "package --install" command? Because right now, that runs in offline mode, and assumes that it should install into a file-based local configuration store. Which means it's subject to all the problems you've raised if the server is not using a file-based local configuration store, etc.
The original purpose of that (in the old offline deployer) was to install the generated configuration in the /deployer's/ config store to that it could be used to resolved dependencies for future deployments. It was the happy co-incidence (ok, a bootstrap hack) that the deployer and server were using the same store that allowed us to pre-load configurations into it.
Of course we use this during server construction. But it might be
best to start the server immediately after bootstrapping the deployer, and
do all the rest of the server construction tasks as online deployments. (That would also have the pleasant side effect of making it all run
faster, because you wouldn't be starting and stopping a kernel for every
deployment.)
I'm all for making it faster but I have reservations about starting the server during the build process as that will trigger a lot of initialization code (like creating a transaction log, a Derby database, etc.) We could nuke it after building the configs but that seems funky.
One thing that was talked about a while ago (off-list probably :-) ) was the concept of having a deployment server that could be used to perform deployments. It would basically be the deployment config running as a Daemon which a deployer could talk to; the server would do the deployment and return the configuration it built to the deployer. As the configurations were portable they could then be moved around to the servers where they were intended to run.
If we changed the bootstrap code to build such a deployment server, then it could used during the build process and we would not have to create new JVMs all the time.
It should be possible to boot such a server inside the Maven VM and talk to it directly. In fact, with a couple of minor tweaks that might even be possible with the current standalone deployment config.
Then the bootstrapping would be the only operation that actually installed in offline mode, and we could remove the unsafe "--install" option from the package command -- or actually make the package command perform the installation in online mode, if we have a deployment module that knows how to deploy a "CAR" file. Or better yet, have the package command run in reverse order -- first distribute the configuration into the running server, and then dump a CAR file from the configuration in the config store.
Aside from building the initial deployer (the hard coded Bootstrap class) I don't think we should do anything special to build the default server configuration. We should be able to do it the same way any other user would configure their own server.
The challenge facing us and any other user is the same - pre-loading a server's configuration store. The command line executable "CAR" can be built by the standalone deployer as can all of its configurations. The problem is how to get them into the new server's store(s).
As I've said before, we currently hack this by making the deployer and server use the same store but we really need to find a general solution.
I have a half-baked idea about a special type of bootstrap deployment where the deployer would interact with a fledging server to set up its stores and repositories and then install the appropriate jars and configurations. This would be driven by bootstrap plan (probably in XML) that told it what to do. I need to think a bit more and I'll send in a proposal to the list when its a little more done.
Hey, perhaps we could discuss this off-list at ApacheCon ;-)
-- Jeremy
