Description of problem: When you use the tag <rhq:archive> in a RHQ recipe provisioning for zip/jar files RHQ extract the content inside the destination path. But some times you want to a pkg in zip format like a WAR/EAR inside the App Server. Version-Release number of selected component (if applicable): RHQ 3.0.0/JON 2.4 Would be nice if you could have a property to instruct RHQ provisioning engine to repackaging your file after the process. As Mazz suggested in [1] would be something like this: <rhq:archive name="MyApp.war" exploded="false"> <rhq:replace> ... </rhq:replace> </rhq:archive> Additional info: This issue was discussed on Rhq/Jopr forum in a thread [1]. [1] http://community.jboss.org/message/564109#564109
note: this would probably involve enhancing org.rhq.core.util.updater.Deployer (perhaps somewhere in or around extractZipAndRawFiles method). And of course we'd have to enhance org.rhq.bundle.ant.type.ArchiveType to add this new "exploded" attribute.
master branch commit: d31fc63f7d6ea1116ef1884941ed869213fe3600 a few unit tests were created to show this working, see: org.rhq.bundle.ant.AntLauncherTest testInstallCompressedZipNoDryRun() testInstallCompressedZipDryRun() testInstallCompressedZipWithTemplatizedFilesNoDryRun testInstallCompressedZipWithTemplatizedFilesDryRun To test this feature, just create a bundle with an archive whose attribute "exploded" is set to false. After you deploy that bundle to an agent, see that the archive remains as a zip file and not exploded. Note: if you ask to <replace> tokens in that archive, then your original zip will be exploded, its templatized files modified to have their tokens replaced, and the content will be zipped back up. This means your original zip file will be different than the zip file placed on the agent box. But this is nothing new and to be expected, just wanted to point this out since you can't just compare filesizes or MD5s of the original zip and the deployed zip. Note2: in the above case (you are not deploying the archive zip exploded, but you do need templatized files modified with their replacement values), when we re-zip up the file, we create the zip file with individual file entries (e.g. "myfile.txt", "subdir/myotherfile.txt") but we do not explicitly add directory entries in the zip file (that is, you won't see an explicit zip entry for "subdir/"). I think this is OK, but I'm not 100% sure if other software that wants to use zips wants to see explicit directory entries. May have to revisit this if it is deemed to be a problem. FWIW, my zip utility on Fedora can read and manipulate these zips fine. Note3: if you have no <replace> elements in your <archive> element in your recipe, we do a raw copy of the original zip to the deployed zip (we don't run it through the template engine).
Verified on build 140 (Version: 4.1.0-SNAPSHOT Build Number: 5905b70) Created a recipe without <replace> elements in <archive> element as below: <rhq:archive name="test.zip" exploded="false"> </rhq:archive> Created and deployed the bundle to the agent and verified that the archive remains as a zip file and not exploded. Aslo created a recipe with <replace> elements in <archive> element as below: <rhq:archive name="test.zip" exploded="false"> <rhq:replace> <rhq:fileset includes="**/*.properties"/> </rhq:replace> </rhq:archive> The app.zip has a templatized properties file (using a variable @@listener.port@@) Created and deployed the bundle to the agent and verified that the archive remains as a zip file. And the templatized properties file within the app.zip file is modified with the replacement value.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.