Cleaning up deployment (unifying services and 88)

[Jeremy Boynes <je...@coredevelopers.net>]

We currently have two different models for deployment:
* -service.xml files
* J2EE modules via the JSR88 API

The way these are being handled is similar but slightly different and 
this is causing problems bootstrapping the installation.

I am going to try and unify these two approaches as follows...

Each deployment plugin (Nova, Jetty, Connector) currently provides an 
implementation of DeploymentConfigurationFactory which is used by the 88 
plugin to configure/distribute each module type.

We also have a ServiceDeployer which handles -service.xml files. I am 
going to turn this into another GBean just like the module deployers. 
For simplicity, I am going to add a Geronimo-specific ModuleType SERVICE 
that represents this service type (the 88 spec provides ways for a 
vendor to do this).

The old DeployCommand will be refactored to create a DeploymentManager 
that has been extended to allow for deployments containing multiple 
source archives. With this (proprietary) API call, you will be able to 
bundle multiple DeployableObjects together into a single Configuration. 
We will also extend the EAR deployer to allow it to contain SERVICE 
modules inside - this will allow developers to create bundles combining 
applications with configuration information needed to run them.

Having DeployCommand use the same infrastructure as 88 will simplify the 
APIs.

The build will generate a executable CAR called "deployer.car" which 
will provide a command-line tool for deploying components. This CAR will 
comprise a Geronimo Configuration with deployers for all J2EE types plus 
SERVICE. It will be used in the assembly stage of the build to generate 
the default server configuration; it can also be used afterward to 
deploy any modules.

-- 
Jeremy

Re: Cleaning up deployment (unifying services and 88)

[David Jencks <da...@coredevelopers.net>]

On Friday, February 6, 2004, at 11:46 AM, Jeremy Boynes wrote:

> We currently have two different models for deployment:
> * -service.xml files
> * J2EE modules via the JSR88 API
>
> The way these are being handled is similar but slightly different and 
> this is causing problems bootstrapping the installation.
>
> I am going to try and unify these two approaches as follows...
>
> Each deployment plugin (Nova, Jetty, Connector) currently provides an 
> implementation of DeploymentConfigurationFactory which is used by the 
> 88 plugin to configure/distribute each module type.
>
> We also have a ServiceDeployer which handles -service.xml files. I am 
> going to turn this into another GBean just like the module deployers. 
> For simplicity, I am going to add a Geronimo-specific ModuleType 
> SERVICE that represents this service type (the 88 spec provides ways 
> for a vendor to do this).
>
> The old DeployCommand will be refactored to create a DeploymentManager 
> that has been extended to allow for deployments containing multiple 
> source archives. With this (proprietary) API call, you will be able to 
> bundle multiple DeployableObjects together into a single > Configuration.

This will require a deployment plan schema whose only purpose is to 
hold multiple deployment plans, correct?  If so I have one I could 
check in.  It provides the configID and the sub plan.

xmlbeans handling of any elements is a little awkward.  Perhaps we 
could define an extensible base schema type for the sub-plans: I 
haven't tried it yet but it might make the xmlbeans stuff easier.

> We will also extend the EAR deployer to allow it to contain SERVICE 
> modules inside - this will allow developers to create bundles 
> combining applications with configuration information needed to run 
> them.

+10
>
> Having DeployCommand use the same infrastructure as 88 will simplify 
> the APIs.
+100 I wondered if this was possible.

thanks
david jencks
>
> The build will generate a executable CAR called "deployer.car" which 
> will provide a command-line tool for deploying components. This CAR 
> will comprise a Geronimo Configuration with deployers for all J2EE 
> types plus SERVICE. It will be used in the assembly stage of the build 
> to generate the default server configuration; it can also be used 
> afterward to deploy any modules.
>
> -- 
> Jeremy
>