This deploys a bundle of files within a zip archive to a managed directory. This follows rpm-like rules when updating a deployment and files already exist in previous deployments that need to be re-installed in an updated deployment. The rules are as follows, where the first three columns represent a file's hashcode:
ORIGINAL | CURRENT | NEW | What To Do... |
X | X | X | New file is installed over current* |
X | X | Y | New file is installed over current |
X | Y | X | Current file is left as-is |
X | Y | Y | New file is installed over current* |
X | Y | Z | New file is installed over current, current is backed up |
none | ? | ? | New file is installed over current, current is backed up |
X | none | ? | New file is installed |
? | ? | none | Current file is backed up and deleted |
(*) denotes that the current file could have been left as-is. If, in the future, we can provide Java with a way to change file permissions or ownership, we would want to copy the new file over the current file and perform the chown/chmod. Here you can see that there is only one non-trivial case where the new file is
not installed, and that is when the original file and the new file have the same hashcode (i.e. was not changed) but the current version of that file was changed (in the trivial case, where there is no new file, nothing is installed and the current file is uninstalled). In this case, since the original file and the new file are identical, the file with the modifications made to the original version (called the "current" version) is presumed to still be valid for the new version, thus we leave the current, modified file in place. In the case where there is ambiguity as to what the right thing to do is, the current file is backed up prior to being overwritten with the new file. This can occur in two cases: the first is when the current file is a modified version of the original and the new file is different from the original; the second is when there was no original file, but there is now a current file on disk and a new file to be installed. In either case, the current file is backed up before the new file is copied over top the current file. Files that need to be backed up will have its backup copied to new deployment's metadata directory, under the backup subdirectory called {@link DeploymentsMetadata#BACKUP_DIR}. If a file that needs to be backed up is referred to via an absolute path (that is, outside the destination directory), it will be copied to the {@link DeploymentsMetadata#EXT_BACKUP_DIR} directory foundin the metadata directory.
@author John Mazzitelli