このトピックでは、自己完結型アプリケーションのパッケージの生成方法について説明します。自己完結型アプリケーションには、JavaやJavaFXアプリケーション、およびアプリケーションの実行に必要なJREが含まれます。
このトピックの内容は次のとおりです。
Javaパッケージ化ツールでは、いくつかの形式の自己完結型アプリケーション・パッケージの組込みサポートが提供されています。基本パッケージは、すべてのアプリケーション・リソースおよびJREを含むハード・ドライブ上の単一のフォルダです。パッケージはそのまま再配布することができ、インストール可能なパッケージ(たとえばEXEやDMG形式)をビルドできます。
プロセスの観点からは、自己完結型アプリケーション・パッケージの作成は、第5章「パッケージ化の基本」で説明されている基本的なアプリケーション・パッケージの作成と似ていますが、次の点が異なります。
<fx:deploy>
Antタスクまたはjavapackager
ツールに追加の引数を渡すことで、自己完結型アプリケーション・パッケージを明示的に要求する必要があります。
特定の形式でパッケージをビルドできるように、オペレーティング・システムおよびツール要件を満たしている必要があります。
自己完結型アプリケーション・パッケージは、JDK 7 Update 6以降を使用した場合のみビルドできます。
基本的な自己完結型アプリケーション・パッケージを作成することは容易ですが、特定の配布方法に最適なユーザー操作性を実現するように自己完結型アプリケーション・パッケージを調整するには、通常、労力と、トピックに関する深い理解が必要です。
自己完結型アプリケーション・パッケージを使用することがアプリケーションのデプロイに最適な方法であるかどうかの判断は、要件に応じて異なります。
自己完結型アプリケーション・パッケージには次の利点があります。
ユーザーは、使い慣れたインストーラでアプリケーションをインストールし、通常の方法で起動します。
アプリケーションで使用するJREのバージョンを制御します。
JREをインストールする必要なしに、アプリケーションを新しいシステムにデプロイできます。
ZIPまたはユーザー・レベルのインストーラを使用すると、管理権限がなくてもデプロイメントが行われます。
アプリケーションのためにファイルの関連付けを登録できます。
セカンダリ・ランチャのサポートにより、アプリケーション・スイートを単一の自己完結型アプリケーション・パッケージにバンドルできます。
自己完結型アプリケーション・パッケージには次の欠点があります。
「ダウンロードして実行」ユーザー操作
Webデプロイメントとは異なり、ユーザー操作は「Webからアプリケーションを起動」に関するものではありません。「ダウンロード、インストールして実行」プロセスの1つで、ユーザーは、アプリケーションを起動するために追加のステップが必要になることがあります。たとえば、ユーザーは、ブラウザまたはオペレーティング・システムのセキュリティ・ダイアログを受け入れたり、ダウンロード・フォルダからアプリケーション・インストーラを検索および起動したりする必要がある場合があります。
ダウンロード・サイズが大きい
一般に、自己完結型アプリケーション・パッケージのサイズは、JREのプライベート・コピーが含まれているため、スタンドアロン・アプリケーションのサイズより大きくなります。
ターゲット・プラットフォーム当たりのパッケージ
自己完結型アプリケーション・パッケージは、プラットフォーム固有で、ビルドしたシステムと同じシステムにのみ作成できます。Windows、LinuxおよびOS Xで自己完結型アプリケーション・パッケージを配信するには、3つのすべてのプラットフォーム上にプロジェクトをビルドする必要があります。
アプリケーションの更新は開発者の担当
Web配備されたJavaアプリケーションは、アプリケーションの更新が使用可能になるとすぐに、Webからその更新を自動的にダウンロードします。Javaの自動更新メカニズムでは、毎年数回、最新のセキュアなバージョンへのJREの更新を処理します。自己完結型アプリケーションには、自動更新の組込みサポートがありません。
各自己完結型アプリケーション・パッケージには、次のアイテムが含まれています。
一連のJARファイルにパッケージ化されたアプリケーション・コード、およびその他のアプリケーション・リソース(データ・ファイル、ネイティブ・ライブラリ)
このアプリケーションのみで使用されるJREのコピー
アプリケーションのネイティブ・ランチャ。1つのパッケージに対する複数のランチャがサポートされています
アイコンなどのメタデータ
複数のパッケージ形式が可能です。パッケージのいくつかのタイプに組込みサポートが提供されます。たとえば、ZIPファイルとしてアプリケーションを配布する場合、フォルダとしてパッケージ化された自己完結型アプリケーションの後処理によって独自のパッケージを構築することもできます。
自己完結型アプリケーション・パッケージの基本形式は、図7-1の例などのハード・ドライブ上の単一フォルダです。パッケージのいずれかをインストールすると、結果は同じコンテンツのフォルダとなります。
自己完結型アプリケーション・フォルダの内部構造は、プラットフォーム固有で、将来変更される可能性があります。ただし、次のアイテムはすべてのプラットフォームに適用され、変更されない可能性があります。
第5章「パッケージ化の基本」に定義されているように、アプリケーション・パッケージはフォルダとして含まれ、アプリケーション・ディレクトリ構造を保持します。
JREのコピーは別のフォルダとして含まれ、JREディレクトリ構造は保持されます。
ディレクトリ構造が保持されるため、アプリケーションは、アプリケーションJARまたはjava.home
システム・プロパティに相対的なパスを使用して外部リソースをロードできます。
注意: デフォルトでは、JREのサブセットのみが含まれます。オプションでめったに使用されないファイル(すべての実行可能ファイルなど)は、パッケージ・サイズを削減するために除外されます。デフォルトで含まれないものが必要な場合、次の後処理ステップとしてコピーする必要があります。インストール可能なパッケージの場合、自己完結型アプリケーション・フォルダへの格納後に実行されるconfig スクリプトからこれを行うことができます。7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」を参照してください。 |
自己完結型アプリケーションを作成する最も容易な方法は、デプロイメント・タスクを変更することです。実行中のプラットフォームのすべてのタイプの自己完結型アプリケーション・パッケージの作成を要求するには、例7-1
に示すように、nativeBundles="all"
を<fx:deploy>タスクに追加します。
例7-1 すべての自己完結型アプリケーション・パッケージを作成する単純なデプロイメント・タスク
<fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" nativeBundles="all" outdir="${basedir}/${dist.dir}" outfile="${application.title}"> <fx:application name="${application.title}" mainClass="${javafx.main.class}"/> <fx:resources> <fx:fileset dir="${basedir}/${dist.dir}" includes="*.jar"/> </fx:resources> <fx:info title="${application.title}" vendor="${application.vendor}"/> </fx:deploy>
作成する正確なパッケージ形式を指定することもできます。値image
を使用して、基本パッケージ(EXEインストーラを要求するにはexe
、DMGインストーラを要求するにはdmg
など)を作成します。属性値の完全なリストは、Antタスク・リファレンスの<fx:deploy>
エントリのnativeBundles属性を参照してください。
Javaパッケージャ・ツールを使用して、ネイティブ・パッケージを作成することもできます。自己完結型アプリケーション・パッケージは、-makeall
コマンドを使用するときにデフォルトでビルドされます。-native
オプションを-deploy
コマンドと一緒に使用して、特定の形式を要求できます。Windows
、またはSolaris、LinuxまたはOS Xのjavapackagerコマンド・リファレンスを参照してください。
例7-2は、BrickBreakerアプリケーションに適用可能なすべての自己完結型アプリケーション・パッケージの生成に使用される、-deploy
コマンドとともに使用する-native
オプションの使用を示しています。-deploy
コマンドは入力としてJARファイルが必要であるため、dist/BrickBreaker.jar
がすでにビルドされていることを前提としています。
パッケージ化ツールでは、アプリケーション・アイコンまたは構成ファイルなどのパッケージを作成するいくつかの組込みリソースを使用します。生成されるパッケージをカスタマイズする1つの方法は、組込みリソースをカスタマイズされたバージョンで置き換えることです。
次のアクションが必要です。
どのリソースが使用されているかを理解します。
パッケージ化ツールが検索している場所にカスタム・リソースをドロップします。
次の各項では、カスタム・リソースの使用方法について説明します。
どのリソースが使用されているかを詳細に理解するには、verbose="true"
属性を<fx:deploy>
に追加するか、-v
オプションをjavapackager -deploy
コマンドに渡すことによって、冗長モードを有効にします。
冗長モードには、次のアクションが含まれます。
次のアイテムが印刷されます。
生成しているパッケージに使用される構成リソースのリスト
各リソースの役割
目的のカスタム・リソース名
自己完結型パッケージの作成に使用される構成ファイルおよびリソースのコピーは、一時フォルダに保存されます。これらのファイルをカスタマイズの開始点として使用できます。
例7-3はサンプル出力を示しています。重要な部分は太字になっています。
例7-3 冗長モードのサンプル出力
Using base JDK at: /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk Using default package resource [Bundle config file] (add package/macosx/Info.plist to the class path to customize) Using default package resource [icon] (add package/macosx/DemoApp.icns to the class path to customize) Creating app bundle: /tmp/test/TestPackage/bundles/DemoApp.app Config files are saved to /var/folders/rd/vg2ywnnx3qj081sc5pn9_ vqr0000gn/T/build7039970456896502625.fxbundler/macosx. Use them to customize package.
構成ファイルのコピーを取得して、必要に合せて調整できるようになります。たとえば、構成ファイルInfo.plist
を取得し、ローカライズされたパッケージ名を追加できます。
注意: カスタマイズを行った後、冗長モードを無効にするか、サンプル構成ファイルを削除するカスタム・クリーンアップ・アクションを追加することをお薦めします。 |
パッケージ化ツールは、組込みリソースに戻す前にクラス・パスでカスタマイズされたリソースを検索します。Javaパッケージャには、デフォルトでクラス・パスに追加された"." (現在の作業ディレクトリ)があります。そのため、アプリケーション・アイコンを置き換えるには、javapackager
が実行されるディレクトリ(通常はルート・プロジェクト・ディレクトリ)の./package/macosx/DemoApp.icns
にカスタム・アイコンをコピーします。
タスク定義がロードされると、Java Antタスクのクラス・パスが定義されます。パスant-javafx.jar
の前のルックアップに追加のパスを追加する必要があります。
例7-4は、クラス・パスに"."を追加する方法を示しています。コードの詳細な例は、例6-1を参照してください。
例7-4 JavaFX Antタスクのリソースのカスタマイズの有効化
<taskdef resource="com/sun/javafx/tools/ant/antlib.xml" uri="javafx:com.sun.javafx.tools.ant" classpath=".:path/to/sdk/lib/ant-javafx.jar"/>
カスタマイズ化されたリソースを指定した後、冗長ビルド出力は、リソースが使用されていることをレポートします。たとえば、アプリケーションにカスタム・アイコンを追加した場合、例7-5に示すように、冗長出力はその追加内容をレポートします。
例7-5 カスタマイズされたアイコン・リソースの追加後の冗長出力
Using base JDK at: /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk Using default package resource [Bundle config file] (add package/macosx/Info.plist to the class path to customize) Using custom package resource [icon] (loaded from package/macosx/DemoApp.icns on class path) Creating app bundle: /tmp/test/TestPackage/bundles/DemoApp.app
自己完結型アプリケーション・パッケージをカスタマイズするには、既存のJava Ant要素の多くが使用されます。異なるパッケージには異なるパラメータ・セットが必要で、同じ要素が異なる役割を持つ場合があります。表7-1に、カスタマイズ・オプションの大部分を紹介します。
表7-1 Ant要素および属性を使用したカスタマイズ・オプション
要素 | 属性 | 詳細 |
---|---|---|
|
|
アプリケーション識別子。形式は、プラットフォームおよびパッケージ固有です。指定しない場合、値が生成されます。 |
|
アプリケーションのバージョン。デフォルトは |
|
|
アプリケーションの短縮名。ほとんどのバンドラでは、出力パッケージの名前の作成にこの名前を使用します。指定しない場合、メイン・クラスの名前が使用されます。 |
|
|
|
デスクトップ・ショートカット要求。 |
|
メニュー・エントリ要求。trueに設定した場合、アプリケーション・メニューのエントリが要求されます。 |
|
|
インストールの範囲。 |
|
|
|
自己完結型アプリケーション・パッケージを構築するプロセスにおけるファイルの役割。タイプ |
|
|
アプリケーション・タイトル。 |
|
アプリケーション・ベンダー。 |
|
|
アプリケーション・カテゴリ。カテゴリ名はパッケージ形式固有です。 |
|
|
ライセンス・タイプ(たとえばGPL)。この属性はLinuxバンドルでのみ使用されます。 |
|
|
短いコピーライト文。 |
|
|
アプリケーションの説明。 |
|
|
起動時にアプリケーションに渡される引数。 |
|
|
アプリケーションに関連付けるファイルのタイプ。 |
|
|
JVMに渡され、アプリケーションの実行に使用されるJVM引数(たとえば大きいヒープ・サイズなど)。 |
|
|
JVMに渡され、アプリケーションの実行に使用される、ユーザー変更可能なJVM引数。詳細は、5.8.2.1項「ユーザーJVM引数の指定」を参照してください。 |
|
|
アプリケーションを実行するJVMで設定されるプロパティ。 |
自己完結型アプリケーション・パッケージの基本形式の作成およびカスタマイズは非常に簡単なプロセスですが、次の点に注意してください。
異なるプラットフォームには異なるアイコン・タイプが必要です。
たとえば、Windowsでは.ico
形式が必要で、Linuxでは.png
形式およびOS Xでは .icns
形式が必要です。Linuxではランチャにアイコンは埋め込まれておらず、かわりに.desktop
ファイルがアイコンを参照します。
JavaFXアプリケーションでは、アイコンをアプリケーション・ステージに追加して、アイコンが実行時に設定されていることを確認します。たとえば、JavaFXアプリケーションのstart()
メソッドに次のコードを追加します。
stage.getIcons().add(new
Image(this.getClass().getResourceAsStream("app.png")));
アプリケーションを配布する場合、出力フォルダのファイルに署名します。
たとえば、Windowsでは、signtool.exe
を使用して起動ツールの実行ファイルに署名できます。
OS Xで生成されるパッケージは"application bundle"です。
いくつかの構成パラメータがアプリケーション・バンドルのInfo.plist
ファイルに配置され、次のルールに従う必要があります。
アプリケーションID (IDが指定されていない場合はメイン・クラス名)はCFBundleIdentifier
として使用されます。
アプリケーション・バージョンはCFBundleShortVersionString
として使用されます。
OS X 10.8ではGatekeeperが導入され、このコードがオブジェクティブCまたはJavaのどちらで実装されているかに関係なく、デフォルトで信頼されていないコードの実行を防ぎます。
ユーザーは実行するアプリケーションを手動で有効にできますが、これは完璧なユーザー操作ではありません。最適なユーザー操作を得るには、AppleからDeveloper ID証明書を取得します。Macバンドラでは、証明書を使用して.app
フォルダに署名します。ローカル・ユーザー情報が証明書の名前と異なる場合、次の例に示すように、バンドル引数mac.signing-key-user-name
を設定する必要がある可能性があります。
例7-6 mac.signing-key-user-nameの使用例
// Using javapackager tool javapackager ... -Bmac.signing-key-user-name="Jane Appleseed" // Using Ant tasks <fx:deploy> //... <fx:bundleArgument arg="mac.signing-key-user-name" value="Jane Appleseed"/> //... </fx:deploy>
詳細は、Apple DeveloperサイトのDeveloper IDおよびGatekeeperに関するトピックを参照してください。
コマンドラインから自己完結型アプリケーションが起動される際に、アプリケーションに引数を渡すことができます。引数が指定されていない場合は、アプリケーションに渡す引数のセットを定義することもできます。デフォルトの引数を定義するには、javapackager deploy
コマンドで-argument
オプションを使用するか、アプリケーション・パッケージの作成時にAntタスクで<fx:argument>要素を使用します。コマンドラインから入力された引数は、デフォルトの引数に優先されます。アプリケーションがランチャ・アイコンから起動される場合、デフォルトの引数が使用されます。
アプリケーションのファイルの関連付けを登録するように自己完結型アプリケーションのインストーラを設定できます。Antタスクで<fx:association>要素を使用して、アプリケーションによって処理できるファイルを識別します。ファイルの関連付けは、ファイル拡張子またはMIMEタイプに基づきます。
次の例では、アプリケーションをMIMEタイプがapplication/x-vnd.MyAppFile
のファイルに関連付けます。
<fx:info title="Association example"> <fx:association mimetype="application/x-vnd.MyAppFile" description="Sample Test Files"> </fx:association> </fx:info>
自己完結型アプリケーションのパッケージを構築して、複数のエントリ・ポイントを持つ製品スイートをサポートできます。各エントリ・ポイントには独自のショートカットまたはアイコンがあります。<fx:application>要素のmainClass
属性では、プライマリ・エントリ・ポイントを識別します。<fx:deploy>タスクで<fx:secondaryLauncher>要素を使用して、各セカンダリ・エントリ・ポイントを定義します。
注意: 複数のエントリ・ポイントは、WindowsおよびLinuxアプリケーションに対してのみサポートされます。 |
次の例では、WindowsのTestSuite
アプリケーションのエントリ・ポイントを定義します。
<fx:deploy outdir="test/apps" nativeBundles="image"> <fx:application name="TestSuite Sample" mainClass="samples.TestSuite"/> <fx:info title="Test Suite"/> <fx:secondaryLauncher mainClass="samples.TestSuite" name="Suite Applications"/> shortcut="true"/> <fx:secondaryLauncher name="Editor"> <fx:bundleArgument arg="icon" value="../resources/editor.ico"/> </fx:secondaryLauncher> <fx:secondaryLauncher name="Spreadsheet"> <fx:bundleArgument arg="icon" value="../resources/spreadsheet.ico"/> </fx:secondaryLauncher> </fx:deploy>
配布を簡略化するために、自己完結型アプリケーションをプラットフォーム固有のインストール可能なパッケージにラップすることができます。サード・パーティ製ツールの可用性に応じて、Javaパッケージ化ツールでは、いくつかの形式のインストール可能なパッケージの組込みサポートが提供されています。
この章の他の項で説明されているように、インストール・プロセスのユーザー操作の調節は、特定のインストーラ・テクノロジに固有です。ただし、必要なインストーラのタイプを決定する必要があります。その決定に役立つ考慮事項は次のとおりです。
システム全体のインストールとユーザーごとのインストールのどちらですか。
システム全体のインストールの結果、パッケージが共有の場所にインストールされ、システム上のどのユーザーも使用できるようになります。通常は管理権限が必要で、インストール・プロセス中は、高いインストーラ権限を承認するOSプロンプトなど、追加のステップが必要になると考えられます。
ユーザーごとのインストールでは、パッケージをプライベート・ユーザー・ディレクトリにコピーし、管理権限は必要ありません。このタイプのインストールでは、できるだけ少ないダイアログを表示することができ、ユーザーに管理権限がなくてもプログラムを実行できます。
ユーザー・レベルまたはシステム・レベルのインストール可能なパッケージが要求されるたびに、ビルド手順自体には管理権限は必要ありません。
クリックスルー・ライセンスが必要ですか。
一部のインストール可能なパッケージでは、インストールの開始前にライセンス・テキストの表示をサポートしています。インストール・プロセスは、ユーザーがライセンスを受け入れた後にのみ開始します。
どのメニューとデスクトップの統合が必要ですか。
ユーザーは、アプリケーションを容易に起動できる必要があります。そのため、デスクトップのショートカットを配置したり、メニュー内のアプリケーションのリストにアプリケーションを追加することが必要です。
現在の実装には、簡略化するための多くの前提があります。たとえば、インストーラは、パッケージをインストールする場所を選択するようユーザーに要求することはありません。開発者も、インストール場所の制御は限られており、システム全体またはユーザーごとのインストールのみ指定できます。
デフォルトの前提ではニーズを満たさない場合、構成ファイル・テンプレートを調整する(7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」を参照)か、基本的な自己完結型アプリケーションをパッケージ化してからそれをインストール可能なパッケージに自分でラップすることにより、詳細なカスタマイズが可能になります。
次のインストール可能なパッケージ形式がサポートされています。
表7-2 インストール可能なパッケージ形式
パッケージ形式 | インストールの場所(デフォルト・モードは太字) | クリックスルー・ライセンス | 前提条件 |
---|---|---|---|
EXE |
ユーザーごと: システム: |
あり(オプション) |
|
MSI |
ユーザーごと: システム: |
特別なサポートはなし |
|
DMG |
ユーザーごと: ユーザーのデスクトップ・フォルダ システム: /Applications |
あり(オプション) |
|
PKG |
ユーザーごと: ユーザーのデスクトップ・フォルダ システム: /Applications |
あり(オプション) |
|
RPM |
ユーザーごと: サポートなし システム: /opt |
特別なサポートはなし |
|
DEB |
ユーザーごと: サポートなし システム: /opt |
特別なサポートはなし |
|
EXEパッケージを生成するには、Inno Setup 5以降をインストールし、PATH
で使用可能にする必要があります。使用可能であることを検証するには、ビルドを起動するコマンド行またはビルド・スクリプトからiscc.exe
の実行を試行します。
デフォルトでは、生成されたパッケージには次の特性があります。
管理権限は必要ありません。
最少のダイアログ数になるよう最適化されます。
プログラム・メニューまたはデスクトップ・ショートカット、あるいはその両方から参照されます。
インストールの終わりにアプリケーションを起動します。
図7-2は、Windows上にインストール中の自己完結型JavaFXアプリケーションの一般的なダイアログ・ボックスを示しています。
カスタマイズのヒント:
システム全体のインストールを選択した場合、ユーザーは管理権限を持っている必要があり、インストールの終わりにアプリケーションは起動しません。
クリックスルー・ライセンスはサポートされています。.rtf
ファイルが必要です。
インストール・ダイアログに表示されるイメージは、アプリケーション・アイコンとは異なります。
7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されているように、ドロップイン技術を使用してイメージをカスタマイズできます。
現在のバージョンのInno Setupでは、イメージが55x58ピクセルの最大サイズのビットマップ・ファイルであることを想定しています。
JavaFXアプリケーションでは、アイコンをアプリケーション・ステージに追加して、アイコンが実行時に設定されていることを確認します。7.3.5項「基本パッケージのプラットフォーム固有のカスタマイズ」を参照してください。
生成される.exe
パッケージに署名します。
信頼できる認証局(TSA)から証明書を取得してから、Windowsのsigntool.exe
ユーティリティを使用してコードに署名する必要があります。
起動ツール実行可能ファイルに署名するためなど、.exe
ファイルに自己完結型アプリケーション・フォルダをラップする前に、微調整できます。
7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用して、Windowsスクリプト・ファイルを指定します。
注意: 生成されたパッケージがインストールされたアプリケーションのリストに表示されている間は、Windowsインストーラ(MSI)テクノロジは使用されず、GUIDを使用する必要はありません。詳細は、Inno SetupのFAQを参照してください。 |
Windows Installer XML (WiX)ツールセット(WiXとも呼ばれる)を使用して、MSIパッケージが生成されます。WiX 3.8以降が必要で、PATH
で使用できる必要があります。検証するには、ビルドを起動するコマンド行またはビルド・スクリプトからcandle /?
の実行を試行します。
デフォルトでは、生成されたMSIパッケージには次の特性があります。
エンタープライズ・デプロイメント・ツールを使用したデプロイメント用に最適化されます。
システム全体の場所にインストールします。
クリックスルーUIがなく、進捗ダイアログのみが表示されます。
プログラム・メニューまたはデスクトップ・ショートカット、あるいはその両方から参照されます。
インストール・プロセス以外で作成されても、インストール・フォルダのすべてのファイルを削除します。(WiX 3.5以降が必要です。)
アプリケーション識別子のUpgradeCode
としての使用を試行します。
アプリケーション識別子が有効なGUIDではない場合、UpgradeCode
のランダムなGUIDが生成されます。
ProductCode
がランダムに生成されます。
固定製品コードを使用するには、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用して、WiXテンプレート・ファイルをカスタマイズします。
ネットワーク上でMSIパッケージを配布する場合、最適なユーザー操作のためにこれに署名します。
起動ツール実行可能ファイルに署名するためなど、.msi
ファイルに自己完結型アプリケーション・フォルダをラップする前に、微調整することもできます。詳細は、7.4.1項「EXEパッケージ」を参照してください。
カスタムUIをMSIパッケージに追加するには、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用して、Javaパッケージャで使用されるWiXテンプレート・ファイルをカスタマイズします。詳細は、WiXのドキュメントを参照してください。
デフォルトでは、DMGパッケージは単純なドラッグ・アンド・ドロップのインストール操作を提供しています。図7-3は、インストール中のデフォルト動作の例を示しています。
インストール・ウィンドウの外観をカスタマイズするために、カスタム・バックグラウンド・イメージを指定できます。
バックグラウンド・イメージに異なるディメンションがあるか、アイコンを別に配置する必要がある場合、インストール・ビュー内の要素のサイズおよび位置を変更するために使用されるDMG設定スクリプトをカスタマイズする必要もあります。カスタマイズの詳細は、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」を参照してください。
自己完結型アプリケーション・フォルダをラップする前に微調整するには、アプリケーション・フォルダが移入された後で実行する独自のbashスクリプトを指定します。そのようなアクションのスクリプトを、パッケージへのローカリゼーション・ファイルの追加として作成できます。図7-4は、調整されたアプリケーション・インストーラの例を示しています。
Gatekeeperフレンドリなパッケージ(OS X 10.8以降用、7.3.5.1項「OS X」を参照)を作成するには、DMGパッケージのアプリケーションに署名する必要があります。DMGファイル自体には署名する必要はありません。Macバンドラはアプリケーションの署名を処理します。ローカル・ユーザー情報が証明書の名前と異なる場合、例7-6
に示すように、バンドル引数mac.signing-key-user-nameを設定する必要がある可能性があります。
アプリケーションに手動で署名するために、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用して、アプリケーション・バンドルが移入された後で実行する構成スクリプトを指定できます。サンプルDemoApp
の場合、構成スクリプトはpackage/macosx/DemoApp-post-image.sh
にあり、例7-7に示すようなコンテンツがあります。
例7-7 アプリケーションに署名する構成スクリプトの例
echo "Signing application bundle" #Move to the folder containing application bundle cd ../images/dmg.image #do sign codesign -s "Developer ID Application" *.app echo "Done with signing"
DMGインストーラは、テキスト形式で提供されたクリックスルー・ライセンスもサポートしています。リッチ・テキスト形式の使用が必要な場合、license.plist
ファイルを外部で準備し、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用してパッケージに追加します。
DMGパッケージを作成するには、サード・パーティ製ツールは必要ありません。
Linuxのインストール・パッケージの生成では、インストール・パッケージのビルドに必要なネイティブ・ツールがインストールされていることを前提としています。RPMパッケージの場合、通常、これはRPMBuildパッケージおよびその依存を意味します。DEBパッケージの場合、dpkg-deb
および依存が必要です。
パッケージをビルドするには、管理権限は必要ありません。
デフォルトでは、生成されたパッケージには次の特性があります。
アプリケーションを/opt
ディレクトリにインストールします。
ショートカットをアプリケーション・メニューに追加します。
Linuxパッケージの通常の動作であるインストール用のUIはありません。
カスタマイズのヒント:
アプリケーション・メニューの特定のカテゴリにアプリケーションを配置するには、<fx:info>
のcategory属性を使用します。
デスクトップ・メニューの仕様を参照し、カテゴリ名のリストはウィンドウ・マネージャのドキュメントを参照してください。
アイコンは.pngファイルである必要があります。
7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用してビルド・テンプレート・ファイルを調整することによって、高度なカスタマイズが可能です。
使用可能なオプションの詳細は、DEB/RPMのパッケージ化ガイドを参照してください。
次の特性を持つJavaFXアプリケーションがあるシナリオを考えてみます。
サード・パーティ製ライブラリをいくつか使用します。
サード・パーティ製ライブラリの1つはJNIを使用し、System.loadLibrary()
を使用してプラットフォーム固有のネイティブ・ライブラリをロードします。
大きい1GBのヒープが必要です。
インストールに管理権限が必要ない自己完結型アプリケーションとして、このアプリケーションをパッケージ化する必要があります。
アプリケーションがスタンドアロン・アプリケーションとして正しく動作すること、メインJARファイルがdist
フォルダにビルドされること(<fx:jar>を使用)、およびサード・パーティ製ライブラリがdist/lib
ディレクトリにコピーされることを前提としています。
自己完結型アプリケーション・パッケージを構築する方法の1つが例7-8に示され、次のアクションで構成されます。
すべてのアプリケーションJARファイルを含めます。
現在のプラットフォームに適用可能なネイティブ・ライブラリを、タイプ・データのリソースとして追加します。
ファイルセットのベース・ディレクトリがライブラリを含むフォルダに設定されていることを確認します。これにより、ライブラリが最上位のアプリケーション・フォルダに確実にコピーされます。
<fx:preferences install="false"/>
を使用して、ユーザー・レベルのインストールを要求します。
最上位のアプリケーション・フォルダがライブラリ検索パスに追加されるため、System.loadLibrary()
を使用できます。
例7-8は、<fx:deploy>タスクの例を示しています。
例7-8 <fx:deploy>タスクの例
<fx:deploy nativeBundles="all" width="600" height="400" outdir="${basedir}/dist" outfile="NativeLibDemo"> <fx:application name="NativeLib Demo" mainClass="${javafx.main.class}"/> <fx:resources> <!-- include application jars --> <fx:fileset dir="dist" includes="*.jar"/> <fx:fileset dir="dist" includes="lib/*.jar"/> <!-- native libs for self-contained application --> <!-- assume they are stored as native/windows/x86/JNativeHook.dll native/linux/x86_64/libJNativeHook.so .... --> <!-- ensure libraries are included as top level elements to get them on java.library.path --> <fx:fileset dir="${basedir}/native/${os.name}/${os.arch}" type="data"> <include name="*.dll"/> <include name="*.jnilib"/> <include name="*.so"/> </fx:fileset> </fx:resources> <!-- Custom JVM setup for application --> <fx:platform> <fx:jvmarg value="-Xmx1024m"/> <fx:jvmarg value="-verbose:jni"/> <property name="my.property" value="something"/> </fx:platform> <!-- request user level installation --> <fx:preferences install="false"/> </fx:deploy>