Deployment Issues with Repackaged Applications

Introduction

It is sometimes necessary to repackage applications, for instance:

1. To change the configuration embedded within the application
2. To make a modification to the applications java script
3. To rebrand the application, etc

There are a couple of things you need to consider to successfully repackage the application, whether it's a war, jar, xml or some other application.

Otherwise you won't be able to add or update the application successfully.

Issue 1 - The Structure of the application needs to be maintained

To repackage an archived application e.g. a war, ear, jar or zip file it often needs to be unpacked first, a modification made to a file and then repackaged. Some zip/archive tools create an additional directory when unpacking/decompressing archive files.

Solution

It is important that this new parent directory does not become part of the repackaged archive as it changes the file structure of the application and causes issues when adding, updating or assigning the application.

Issue 2 - The manifest.mf file get rewritten

Some applications are created with properties embedded in the archives manifest.mf file. For instance, some palettes 2.0 configuration files have the following property in the manifest file to make use of the pre-installed palettes extension:

Dependencies: com.cafex.palettes.appserver.extension

WINRAR and other jar utilities will rewrite the manifest.mf file when you repackage war,ear,sar and jar archives.

Without this dependency the following error occurs on application update or assignment:

ClassNotFoundException: com.cafex.palettes.PalettesPluginRegistrar

Solution

It this case it is better to re-archive the application as a zip file and manually change the extension afterwards.