I go on a small trip and this thread goes wild - sorry for being late to the "party".
1) I'm adding the zip scanning Jason mentioned to detect whether the zip is complete. This is the basis for reliable auto-deploy of zipped content.
Great - makes perfect sense.
2) Reliable auto-deploy of exploded content is not possible. As a safety aid I will use the scanning code from 1) to check any nested jars, but that doesn't make it reliable.
Okey...not sure if it will worth the hassle/CPU-cycles but worth experimenting with.
3) If auto-deploy is available for a type of content, a .skipdeploy marker will prevent auto-deploy of a particular file.
..particular file or directory, right ?
btw. I really like this "veto" option ;) Much easier to implement from user/tooling perspective.
3) I'm going to add an "auto-deploy" flag to the deployment-scanner element, with legal values "ALL", "ZIPPED", "NONE". Flag controls what types of content auto-deploy behavior is enabled for. Per Jason's statement above, default is "ZIPPED", as "ALL" cannot be made reliable. Configuring "ALL" will result in a WARN message in the server log.
Just to be sure I understand this correctly - this means by default AS7
cp -r foo.war AS7/deployments
will trigger an deployment of foo.war when it is an archive when the scanner sees the war and it is complete.
it will *not* trigger deployment of foo.war when it is a directory. Correct ?
4) For auto-deploy of exploded content, there will be no deployment descriptor file timestamp check as the means of detecting the need to redeploy, as in EE 6 there is no universal requirement for deployment descriptors. And checking the directory timestamp is not valid as it's easy to change content without triggering a change in the directory timestamp. So, with auto-deploy if any file in the deployment changes, the deployment gets redeployed. People who want to change content without triggering redeploy are going to have to use marker files; either leave auto-deploy disabled and use .dodeploy, or enable auto-deploy and use .skipdeploy.
It took me a couple of reads of #3 and #4 to get what this meant but this actually makes perfect sense and gives a good balance
between preventing bad deployments and still have incremental updates of your exploded content.
This basically means the *only* new thing by default is having to do a
touch foo.war.dodeploy
or the more portable:
echo > foo.war.dodeploy
for exploded directories. Everything else is just as "before" but better ;)
i.e. to make it clean its important that if you detect both a complete foo.war and a foo.war.dodeploy the .dodeploy still gets deleted and goes through the transitions; and that there will be a .deployed file no matter what triggered the deploy.
5) If a scan tries to use auto-deploy for a file and detects incomplete content, the scan will be aborted (i.e. it will be as if no changes were detected.) The next time the scanner runs, it will check again.
Perfect from first read, but i'm still curious how long that consistency check will take for large projects ?
And should there be a maximum of redeployment attempts to avoid the logs for filling/cpu cycles burning ?
Maybe have the user made aware of the .dodeploy failing and make it a .deployfailed after some time and thus require a new touch ?
(should be fine since if user is doing .dodeploy we should assume that the deployment is actually expected to be complete?)
AFAICT, this is essentially completing what was discussed in Antwerp and detailed a few pages back by Max. Difference is auto-deploy of exploded content will not be default behavior.
Yes, this works for me :) I basically get all the goodies I wished for.