Related to: http://jira.jboss.com/jira/browse/JBAS-3118
I refactored Andy's initial changes to come up with a hopefully clearer API, that deals with all combinations (not just redeployments) still does want Andy needs:
/**
* Temporarily ignore changes (addition, updates, removal) to a particular
* deployment, identified by its deployment URL. The deployment URL is different
* from the 'base' URLs that are scanned by the scanner (e.g. the full path to
* deploy/jmx-console.war vs. deploy/). This can be used to avoid an attempt
* by the scanner to deploy/redeploy/undeploy a URL that is being modified.
*
* To re-enable scanning of changes for a URL, use resumeDeployment(URL, boolean).
*/
void suspendDeployment(URL url);
/**
* Re-enables scanning of a particular deployment URL, previously suspended
* using suspendDeployment(URL). If the markUpToDate flag is true then the
* deployment module will be considered up-to-date during the next scan.
* If the flag is false, at the next scan the scanner will check the
* modification date to decide if the module needs deploy/redeploy/undeploy.
*/
void resumeDeployment(URL url, boolean markUpToDate);
So the primary scenario is deploy a module normally in deploy/, then suspendDeployment(URL) and change it programmatically (e.g. modify the deployment descriptor, do whatever). Then either rededeploy through the MainDeployer (or not) and resumeDeployment(URL, true) (the scanner won't attempt to redeploy), or just resumeDeployment(URL, false), and the scanner will redeploy in the next round.
The changes also work in the case where:
1) a module is "suspended" but not deployed yet, then copied to deploy dir and resumed (i.e. deployed).
2) a module is "suspended" but deployed, then removed from deploy, and resumed (i.e. undeployed).
If I missed something, let me know. This is both in 4.0.x and HEAD and it still needs tests in the testsuite (so essentially it "doesn't exist :)
