JBossDeveloper

Andrew Rubinger wrote:

 

Do we have a requirements whereby we deploy:

 

File A, URL B, ShrinkWrap C

 

...together, we need to undeploy or query anything less than the full set?

 

I'm thinking of defining a "Deployment" as a "bunch of resources deployed together".  The client then constructs the deployment:

 

Deployment deployment = deploymentBuilder.add(File).add(URL).add(JavaArchive).build()
deployer.deploy ( deployment ) ;

 

Then undeploy and query operations may pass in the same deployment as was initially supplied by the client, rather than some handle returned by the server.  This logically groups all deployable elements of the deployment together as a unit.

 

S,

ALR

They must be deployed together, but each deployment remains a separate unit and can be undeployed separately.  If you want them to be deployed and undeployed as one they must be packaged in an aggregate type like an EAR.

Andrew Rubinger wrote:

 

David Lloyd wrote:

They must be deployed together, but each deployment remains a separate unit and can be undeployed separately.  If you want them to be deployed and undeployed as one they must be packaged in an aggregate type like an EAR.

Then the Deployment API must either return a Handle for every deployment, or use the deployment itself as the Handle for further query/update operations.

 

ie.

 

DeploymentHandle fileHandle = deployer.add(File f);
DeploymentHandle urlHandle = deployer.add(URL u);
deployer.process();
deployer.undeploy(fileHandle);

 

That kills fluidity.

Due to the fact that you've got the possibility of more ancillary information going with the deployment (i.e. deployment plan stuff: do we do a rolling upgrade? what's the rollback policy in case of failure? etc.) I'd say you'd have something more like:

deployer.add(myFile).setRollbackPolicy(whatever).setBlah(blah);
deployer.add(myURL); // defaults
DeploymentResult result = deployer.process();

Then "result" can contain unique identifiers for the deployments installed.  In AS7 it looks like a deployment would be uniquely identified by a name which is derived from the file name, plus an SHA-1 hash.

Andrew Rubinger wrote:

 

David Lloyd wrote:

deployer.add(myFile).setRollbackPolicy(whatever).setBlah(blah);
deployer.add(myURL); // defaults
DeploymentResult result = deployer.process();

 

Then "result" can contain unique identifiers for the deployments installed.  In AS7 it looks like a deployment would be uniquely identified by a name which is derived from the file name, plus an SHA-1 hash.

We still need a way to map the client inputs (ie. File, URL) to something contained in the DeploymentResult.  I think it's easier to just use the references supplied by the client as the handle to query and undeploy as well.

It's just the file name from the argument.

Andrew Rubinger wrote:

 

Also this API has no notion of deployment plans, rolling upgrades, or rollback policies.  It's essentially a version-independent abstraction atop what we now call MainDeployer.  For AS7 to directly support these operations, that'll have to come a level lower.

Ah, well that makes it pretty much irrelevant for our M1 deadline.