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.
Packages the application using a conventional directory layout as found typically in Un*x packages. The directory layout is as follows:
- [root] - contains all files available at
griffon-app/conf/dist/shared
- bin - binary launchers (Windows and Un*x)
- lib - application jars
The application launcher will bear the name of the application.Run it with the following commandArguments:
NoneConfiguration options:
NoneThis 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.Arguments:
name
- override the name of the generated jar file.
Configuration Options:
griffon.jars.jarName
- name of the application's main jar file.
griffon.dist.jar.nozip
- skip zipping the distribution if set to true.
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 availableStrategy | Description |
---|
Skip | Do not perform any merge. Duplicate is discarded. |
Replace | Duplicate is preferred and overwrites previous. |
Append | Duplicate is appended at the end of previous. |
Merge | Common lines found in duplicate are discarded. New lines found in duplicate are appended at the end. |
MergeManifest | Duplicate keys override the previous ones. New keys are added to the merged result. |
MergeProperties | Duplicate keys override the previous ones. New keys are added to the merged result. |
MergeGriffonArtifacts | Merges artifact definitions per type. |
You can specify merging preferences in BuildConfig.groovy
like thisgriffon {
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 tableRegexp | MergeStrategy |
---|
META-INF/griffon-artifacts.properties | MergeGriffonArtifacts |
META-INF/MANIFEST.MF | MergeManifest |
META-INF/services/.* | Merge |
.*.properties | MergeProperties |
Merging preferences must be defined from the most specific to the least. Your preferences will override any default settings.
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.Arguments:
codebase
- specify the codebase to be written in the JNLP file.
Configuration Options:
griffon.dist.webstart.nozip
- skip zipping the distribution if set to true.
- same configuration options used when running in webstart mode.
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.Arguments:
codebase
- specify the codebase to be written in the JNLP file.
Configuration Options:
griffon.dist.applet.nozip
- skip zipping the distribution if set to true.
- same configuration options used when running in applet mode.
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:
izpack
- universal installer using Izpack.
mac
- for MacOSX.
rpm
- for rpm based Linux distributions.
deb
- for .deb based Linux distributions.
jsmooth
- for Windows.
You may call any of these modes as you would with the standard ones when the installer plugin is available, in other wordsMany of these modes support additional configuration before generating the final package. It is a good idea to follow a two-step processgriffon 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
.
Griffon will automatically create the following entries in the application's manifestManifest-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 examplegriffon {
jars {
manifest = [
'Foo': 'Bar'
'Built-By': 'Acme'
]
}
}