11. Packaging and Deployment

Griffon can package applications in several modes. There are 4 modes supported by default: zip, jar, webstart and applet.

To package an application use the package command. All modes will be used when calling the package command with no arguments. You can specify one or more packaging modes when executing the command. Packages will be place in their respective directory inside the dist directory located at the root of the application. You can configure a different default set of deployment targets that will be used when invoking this command without arguments. Simply add a configuration flag to BuildConfig.groovy like this


griffon.packaging = 'zip'

Now, any time you call the package command without arguments only the zip target will be executed.

It is possible to specify files that can be shared across packaging modes, like a README or a LICENSE file. Make sure to place them under griffon-app/conf/dist/shared.

Files that should be packed inside the application's jar META-INF directory must be placed in griffon-app/conf/metainf. This setting works for addons too.

Packaging an application will be executed in the production environment by default. You may specify a different environment as you would with other command. This setting impacts directly how webstart and applet modes are executed, as they will sign and pack all jars by default when in production mode. Please review and update your configuration if you desire a different behavior.

Each packaging target triggers a PackageStart and PackageEnd events, with their type as the single event parameter.

11.1 Zip

Packages the application using a conventional directory layout as found typically in Un*x packages. The directory layout is as follows:

The application launcher will bear the name of the application.

Run it with the following command

griffon package zip

Arguments: None

Configuration options: None

11.2 Jar

This is the simplest packaging mode available. It will package the application in a single jar file, by unpacking all dependencies and packing them once more in a sole file, so place close attention to potential duplicate entries, especially those found inside META-INF.

griffon package jar

Arguments:

Configuration Options:

There's a high chance of some files to have duplicates, e.g. griffon-artifacts.properties if you have installed a plugin that provides MVC groups. It's possible to instruct the build to merge duplicate files by specifying a regular expression and a merging strategy. The following table explains the different merging strategies available

StrategyDescription
SkipDo not perform any merge. Duplicate is discarded.
ReplaceDuplicate is preferred and overwrites previous.
AppendDuplicate is appended at the end of previous.
MergeCommon lines found in duplicate are discarded. New lines found in duplicate are appended at the end.
MergeManifestDuplicate keys override the previous ones. New keys are added to the merged result.
MergePropertiesDuplicate keys override the previous ones. New keys are added to the merged result.
MergeGriffonArtifactsMerges artifact definitions per type.

You can specify merging preferences in BuildConfig.groovy like this

griffon {
    jars {
        merge = [
            '.*.xml': org.codehaus.griffon.ant.taskdefs.FileMergeTask.Replace
        ]
    }
}

This setting will overwrite any XML file found in the path with the last version encountered as jars are processed. The griffon build defines a set of default mappings, which are the ones found in the next table

RegexpMergeStrategy
META-INF/griffon-artifacts.propertiesMergeGriffonArtifacts
META-INF/MANIFEST.MFMergeManifest
META-INF/services/.*Merge
.*.propertiesMergeProperties

Merging preferences must be defined from the most specific to the least. Your preferences will override any default settings.

11.3 Webstart

Packages the application to be used in webstart mode. Will generate an appropriate JNLP file similarly as it's done when running the application in webstart mode.

griffon package webstart

Arguments:

Configuration Options:

11.4 Applet

Packages the application to be used in applet mode. Will generate an appropriate JNLP and Html files similarly as it's done when running the application in applet mode.

griffon package applet

Arguments:

Configuration Options:

11.5 Additional modes

If any of the afore mentioned packaging modes does not suite your needs you may use the Installer plugin to craft a better packaging option. This plugin supports the following additional modes:

You may call any of these modes as you would with the standard ones when the installer plugin is available, in other words

griffon package izpack

Many of these modes support additional configuration before generating the final package. It is a good idea to follow a two-step process

griffon prepare-izpack
// edit target/installer/izpack/resources/installer.xml
// and/or add more files to that directory
griffon create-izpack

Each additional packaging mode triggers 4 events with their type as the single event parameter: PreparePackageStart, PreparePackageEnd, CreatePackageStart and CreatePackageEnd.

11.6 Custom Manifest Entries

Griffon will automatically create the following entries in the application's manifest

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.1
Created-By: ${jvm.version} (${jvm.vendor})
Main-Class: ${griffonApplicationClass} | ${griffonAppletClass}
Built-By: ${user.name}
Build-Date: dd-MM-yyyy HH:mm:ss
Griffon-Version: ${griffonVersion}
Implementation-Title: capitalize(${griffonAppName})
Implementation-Version: ${appVersion}
Implementation-Vendor: capitalize(${griffonAppName})

There might be times when you must specify additional attributes or override existing ones. You can do this by adding a new block of configuration to BuildConfig.groovy, for example

griffon {
    jars {
        manifest = [
            'Foo': 'Bar'
            'Built-By': 'Acme'
        ]
    }
}