We have flexibility in what we tell the user. We just need to come up with something that's meaningful and useful. See the Deployment API thread for some of the things people are looking for. Some of it is pretty rich and detailed. So part of what I'm trying to work toward here is how to lay the foundation for supporting that.
For detailed, intelligent reporting on what's happened with a deployment, for sure some sort of processing based on the type of the deployment is needed. Whether we want to do such detailed, intelligent reporint needs discussion. Part of what I was getting at here though is the DeploymentService seems like a natural place to encapsulate information about a deployment, whatever it may be.
But, ignoring the really rich, detailed reporting cases, what's a reasonable minimum to tell a user?
Simplest is just to report whether the deployment unit passed through the deployment chain without exception and BatchBuilder.install() returned without exception. That's easy enough, since it's all done by one thread. Not sure how useful that is though, since nothing at all is actually started by that thread.
David's concept of tracking the "meat" of the deployment is better, but it's not clear how to implement that. Does that become a deployer responsibility? Deciding the service X is "meat" and somehow registering it with whatever is tracking the overall deployment?
Re: signalAll: oops! thanks for that! The IDE isn't always your friend.