So, people can understand it, I'll document my thinking a bit on why it was add(deployment).andDeploy(). (Cutting to the chase it can probably change.)
- See my post above on 3 different parts of identifying a deployment -- common name, unique internal name, unique external name. That 3rd part unique external name is new from yesterday and is helpful. Without it the user needed a separate add operation so we could hash the deployment and come up with a unique name that's used in the other API methods. If instead we make the user responsible for providing a unique external name, that may simplify things.
- In the domain case, we have a domain level <deployments/> element that lists all available deployments and then at the server-group level a mapping of deployments to server groups. And, within the server-group or on standalone server a deployment can have a start="false" flag. Those two facts imply a separate add operation that only makes content available but doesn't actually trigger deploy.
- There are a lot of overloaded variants of "add". And I expect there will be more; see Jesper's suggestions on this thread, similar things that will probably come from Shrinkwrap. Adding all those overloaded variants to "deploy" and "replace" leads to an very busy API.
But, now I'm less concerned about 3). If the "unique external name" is the id for a deployment, all the methods that take DeploymentUnitKey can go and we're left with the String variants. And if the variants that take "String repository" as a param can go, that again wipes out a lot of overloading. So convenience methods for deploy and replace make sense.