Greg Wilkins ranted:
[...]
So I think the way forward is for:
Aaron - can you think how to cast your proposal in terms of generic
rather than specific APIs, such that the Web app deployer (where ever that
may be) will see the same style of calls for a WAR in EAR deploy as it
would for a direct WAR deploy.
Jan - can you look at you current code and give more details of the steps & process that could like be given up to a common deployer.
Having just chatted to Jan about this - I think I can say this more clearly as:
So I think the way forward is to look at the DeploymentPlanner API and make sure that it conforms to JSR88 (eg at the very least planDeployment should not plan a start step).
This needs to be done at the DeploymentPlanner level so that all deployers (service deployer, ear deployer, war deployer) will conform to JSR88.
We then need to look at how one deployment planner can request the deployment of another unit and for it to supply additional context (eg for the ear deployer to request a war deployment, but with extra DDs).
Finally, we then need to look at the common handling done by all deployers and make sure that is implemented only once (ie in an DeploymentPlannerSupport class or AbstractDeploymentPlanner or as a method of the deployment controller - whatever).
Thus I think that the code that Aaron is talking about will end up in the DeploymenPlannerSupport and in an EARDeploymentPlanner.
The code that Jan is talking about ends up in the Webapp deploymentplanner (which is the WebContainer) and it will use a DeploymentPlannerSupport. It does not really know or care if it get's called to deploy something the deployment scanner found or something that the EARDeploymentPlanner requested, it is all the same to it (except an additional DD will be passed in the context).
cheers
