I set up the deployment with a single “Deploy Java Archive Step”. The deployment completes successfully but the jar gets “corrupted”. The problem is that this predefined step unpacks the JAR, performs the substitutions and then recreates the jar but it also compresses the content at that point. However, the JVM can use the embedded JARs only if they I save into the “uber” jar uncompressed. How can I work around this problem?
At present, Octopus does not support disabling compression when re-packing a jar. We will investigate whether we could possibly support this in the future.
Thanks for the prompt response, David. Leaving the archive unpacked is exactly what I did after I had posted the question. That solution works fine for me. It is only inconvenience of juggling multiple files (deleting the complete tree during redeployment take longer than deleting a single jar) and using a longer command line that would steer me toward using this super jar as a unit. I appreciate your consideration for the feature though. For example, you can replace the current check box for leaving the jar exploded with a three state toggle - exploded, compressed and uncompressed.