Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

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