We need to make the initial deploy to a destination consistent with the update/redeploy to the same destination. Today, the behavior is inconsistent. When you deploy the bundle for the first time to a destination and manageRootDir=false, we do not touch any of the files or subdirectories in the destination directory even when the bundle has the same subdirectory but on redeploy we do cleanup those files not in the bundle. To illustrate: bundle.zip: subdir/foo.txt dest-dir: subdir/bar.txt On initial deploy I end up with: dest-dir: subdir/bar.txt subdir/foo.txt But on update or redeploy I end up with: dest-dir: subdir/foo.txt Bug #801926 is related - that relates to what we want the behavior to actually be in this case. But for this issue, we want to make the behavior consistent one way or the other. I will attempt to fix this so the "update" behavior is how the initial deploy should behave. In other words, after the initial deploy, we should have: dest-dir: subdir/foo.txt because this was the original intent with the bundle system. In other words, the bundle itself defines EVERYTHING under the deployment main directory (so whatever the bundle says should be in subdir should be in subdir - no less and NO MORE). The manageRootDir=false means "do not manage the ROOT directory (only)" but all subdirectories will be fully managed by the bundle (which is why update acts as it does and why I want the initial deploy to work like the update does). See Bug #801926 in regards to whether this SHOULD be the way it works in the future - if not, we will need to keep in mind backwards compat issues, documentation issues and the amount of time it would take to change the behavior of manageRootDir=false. I suspect we will need to add something like "manageSubDirs=false" to do what it currently the initial deploy behavior (that is, leave any existing files alone in all subdirectories). But that's just a guess - again, bug #801926 will track that.
This is a BIG change in behaviour and needs to heavily emphasized in our docs and release notes.
master commit: 53e63b7
Created attachment 570020 [details] no-manage-root-dir.zip a bundle distribution file, no-manage-root-dir.zip, is attached to use to test this. here's how: 1) create a place on your file system to deploy this bundle (e.g. /tmp/testdir) 2) create some "extra" files in here so they are "in the way" of the bundle you will be deploying. These will represent files that would be already existing in an existing destination directory. Create these specific files in order to exercise the fix: /tmp/testdir/subdir/extra-file.txt /tmp/testdir/subdir2/extra-file2.txt /tmp/testdir/extradir/extra-file3.txt /tmp/testdir/extra-file4.txt 3) import a platform and put it into a test group to be used as the target where you will deploy the bundle. 4) upload no-manage-root-dir.zip via the bundle upload wizard 5) deploy the bundle to your test platform group created in step 3, with a bundle destination set to your test directory you created in step 1 (e.g. /tmp/testdir). Now look at what is in your test directory (/tmp/testdir) and make sure a) the subdir/extra-file.txt was removed (it will have been backed up in /tmp/testdir/.rhqdeployments/#####) - this was removed because the bundle declared it will be managing that subdirectory by virtue of the recipe's <rhq:file> whose destinationDir is "subdir" b) the subdir2/extra-file2.txt was removed (it will also have been backed up) - this was removed because the bundle declared it will be managing that subdirectory by virtue of the fact that the recipe declared a <rhq:archive> which has "subdir2" inside of it. c) the two other extra files (extradir/extra-file3.txt and extra-file4.txt) were not removed because the recipe declared manageRootDir=false and extradir and extra-file4.txt were in the root directory (and not otherwise specified by the bundle recipe - so they are to be left alone).
Set components correctly. I opened bug 824577 to track the documentation update for this.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.