My jar contains it dependents like this:
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?
Thank you for the help.
Hi amasniko, and thanks for getting in touch.
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.
In the mean time, are you able to work around this by unzipping the outer jar and booting it as an exploded archive? The Spring Boot documentation has an example of how to do this: https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html#executable-jar-exploded-archives
Please let me know if I can be of further assistance, and thanks for the feedback that helps us make Octopus better.
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.
Glad to hear that worked. And thanks for letting us know; it really helps us smooth these things out.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.