Java Platform, Standard Editionデプロイメント・ガイド
目次      

7 自己完結型アプリケーションのパッケージ化

このトピックでは、自己完結型アプリケーションのパッケージの生成方法について説明します。自己完結型アプリケーションには、JavaやJavaFXアプリケーション、およびアプリケーションの実行に必要なJREが含まれます。

このトピックの内容は次のとおりです。

7.1 はじめに

Javaパッケージ化ツールでは、いくつかの形式の自己完結型アプリケーション・パッケージの組込みサポートが提供されています。基本パッケージは、すべてのアプリケーション・リソースおよびJREを含むハード・ドライブ上の単一のフォルダです。パッケージはそのまま再配布することができ、インストール可能なパッケージ(たとえばEXEやDMG形式)をビルドできます。

プロセスの観点からは、自己完結型アプリケーション・パッケージの作成は、第5章「パッケージ化の基本」で説明されている基本的なアプリケーション・パッケージの作成と似ていますが、次の点が異なります。

  • <fx:deploy> Antタスクまたはjavapackagerツールに追加の引数を渡すことで、自己完結型アプリケーション・パッケージを明示的に要求する必要があります。

  • 特定の形式でパッケージをビルドできるように、オペレーティング・システムおよびツール要件を満たしている必要があります。

  • 自己完結型アプリケーション・パッケージは、JDK 7 Update 6以降を使用した場合のみビルドできます。

基本的な自己完結型アプリケーション・パッケージを作成することは容易ですが、特定の配布方法に最適なユーザー操作性を実現するように自己完結型アプリケーション・パッケージを調整するには、通常、労力と、トピックに関する深い理解が必要です。

7.2 自己完結型アプリケーション・パッケージの利点および欠点

自己完結型アプリケーション・パッケージを使用することがアプリケーションのデプロイに最適な方法であるかどうかの判断は、要件に応じて異なります。

自己完結型アプリケーション・パッケージには次の利点があります。

  • ユーザーは、使い慣れたインストーラでアプリケーションをインストールし、通常の方法で起動します。

  • アプリケーションで使用するJREのバージョンを制御します。

  • JREをインストールする必要なしに、アプリケーションを新しいシステムにデプロイできます。

  • ZIPまたはユーザー・レベルのインストーラを使用すると、管理権限がなくてもデプロイメントが行われます。

  • アプリケーションのためにファイルの関連付けを登録できます。

  • セカンダリ・ランチャのサポートにより、アプリケーション・スイートを単一の自己完結型アプリケーション・パッケージにバンドルできます。

自己完結型アプリケーション・パッケージには次の欠点があります。

  • 「ダウンロードして実行」ユーザー操作

    Webデプロイメントとは異なり、ユーザー操作は「Webからアプリケーションを起動」に関するものではありません。「ダウンロード、インストールして実行」プロセスの1つで、ユーザーは、アプリケーションを起動するために追加のステップが必要になることがあります。たとえば、ユーザーは、ブラウザまたはオペレーティング・システムのセキュリティ・ダイアログを受け入れたり、ダウンロード・フォルダからアプリケーション・インストーラを検索および起動したりする必要がある場合があります。

  • ダウンロード・サイズが大きい

    一般に、自己完結型アプリケーション・パッケージのサイズは、JREのプライベート・コピーが含まれているため、スタンドアロン・アプリケーションのサイズより大きくなります。

  • ターゲット・プラットフォーム当たりのパッケージ

    自己完結型アプリケーション・パッケージは、プラットフォーム固有で、ビルドしたシステムと同じシステムにのみ作成できます。Windows、LinuxおよびOS Xで自己完結型アプリケーション・パッケージを配信するには、3つのすべてのプラットフォーム上にプロジェクトをビルドする必要があります。

  • アプリケーションの更新は開発者の担当

    Web配備されたJavaアプリケーションは、アプリケーションの更新が使用可能になるとすぐに、Webからその更新を自動的にダウンロードします。Javaの自動更新メカニズムでは、毎年数回、最新のセキュアなバージョンへのJREの更新を処理します。自己完結型アプリケーションには、自動更新の組込みサポートがありません。

7.3 基本

各自己完結型アプリケーション・パッケージには、次のアイテムが含まれています。

  • 一連のJARファイルにパッケージ化されたアプリケーション・コード、およびその他のアプリケーション・リソース(データ・ファイル、ネイティブ・ライブラリ)

  • このアプリケーションのみで使用されるJREのコピー

  • アプリケーションのネイティブ・ランチャ。1つのパッケージに対する複数のランチャがサポートされています

  • アイコンなどのメタデータ

複数のパッケージ形式が可能です。パッケージのいくつかのタイプに組込みサポートが提供されます。たとえば、ZIPファイルとしてアプリケーションを配布する場合、フォルダとしてパッケージ化された自己完結型アプリケーションの後処理によって独自のパッケージを構築することもできます。

7.3.1 自己完結型アプリケーション構造

自己完結型アプリケーション・パッケージの基本形式は、図7-1の例などのハード・ドライブ上の単一フォルダです。パッケージのいずれかをインストールすると、結果は同じコンテンツのフォルダとなります。

自己完結型アプリケーション・フォルダの内部構造は、プラットフォーム固有で、将来変更される可能性があります。ただし、次のアイテムはすべてのプラットフォームに適用され、変更されない可能性があります。

  • 第5章「パッケージ化の基本」に定義されているように、アプリケーション・パッケージはフォルダとして含まれ、アプリケーション・ディレクトリ構造を保持します。

  • JREのコピーは別のフォルダとして含まれ、JREディレクトリ構造は保持されます。

ディレクトリ構造が保持されるため、アプリケーションは、アプリケーションJARまたはjava.homeシステム・プロパティに相対的なパスを使用して外部リソースをロードできます。


注意:

デフォルトでは、JREのサブセットのみが含まれます。オプションでめったに使用されないファイル(すべての実行可能ファイルなど)は、パッケージ・サイズを削減するために除外されます。デフォルトで含まれないものが必要な場合、次の後処理ステップとしてコピーする必要があります。インストール可能なパッケージの場合、自己完結型アプリケーション・フォルダへの格納後に実行されるconfigスクリプトからこれを行うことができます。7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」を参照してください。

7.3.2 基本的なビルド

自己完結型アプリケーションを作成する最も容易な方法は、デプロイメント・タスクを変更することです。実行中のプラットフォームのすべてのタイプの自己完結型アプリケーション・パッケージの作成を要求するには、例7-1に示すように、nativeBundles="all"<fx:deploy>タスクに追加します。

作成する正確なパッケージ形式を指定することもできます。値imageを使用して、基本パッケージ(EXEインストーラを要求するにはexe、DMGインストーラを要求するにはdmgなど)を作成します。属性値の完全なリストは、Antタスク・リファレンスの<fx:deploy>エントリのnativeBundles属性を参照してください。

Javaパッケージャ・ツールを使用して、ネイティブ・パッケージを作成することもできます。自己完結型アプリケーション・パッケージは、-makeallコマンドを使用するときにデフォルトでビルドされます。-nativeオプションを-deployコマンドと一緒に使用して、特定の形式を要求できます。Windows、またはSolaris、LinuxまたはOS Xjavapackagerコマンド・リファレンスを参照してください。

例7-2は、BrickBreakerアプリケーションに適用可能なすべての自己完結型アプリケーション・パッケージの生成に使用される、-deployコマンドとともに使用する-nativeオプションの使用を示しています。-deployコマンドは入力としてJARファイルが必要であるため、dist/BrickBreaker.jarがすでにビルドされていることを前提としています。

7.3.3 ドロップイン・リソースを使用したパッケージのカスタマイズ

パッケージ化ツールでは、アプリケーション・アイコンまたは構成ファイルなどのパッケージを作成するいくつかの組込みリソースを使用します。生成されるパッケージをカスタマイズする1つの方法は、組込みリソースをカスタマイズされたバージョンで置き換えることです。

次のアクションが必要です。

  • どのリソースが使用されているかを理解します。

  • パッケージ化ツールが検索している場所にカスタム・リソースをドロップします。

次の各項では、カスタム・リソースの使用方法について説明します。

7.3.3.1 カスタム・リソースの準備

どのリソースが使用されているかを詳細に理解するには、verbose="true"属性を<fx:deploy>に追加するか、-vオプションをjavapackager -deployコマンドに渡すことによって、冗長モードを有効にします。

冗長モードには、次のアクションが含まれます。

  • 次のアイテムが印刷されます。

    • 生成しているパッケージに使用される構成リソースのリスト

    • 各リソースの役割

    • 目的のカスタム・リソース名

  • 自己完結型パッケージの作成に使用される構成ファイルおよびリソースのコピーは、一時フォルダに保存されます。これらのファイルをカスタマイズの開始点として使用できます。

例7-3はサンプル出力を示しています。重要な部分は太字になっています。

構成ファイルのコピーを取得して、必要に合せて調整できるようになります。たとえば、構成ファイルInfo.plistを取得し、ローカライズされたパッケージ名を追加できます。


注意:

カスタマイズを行った後、冗長モードを無効にするか、サンプル構成ファイルを削除するカスタム・クリーンアップ・アクションを追加することをお薦めします。

7.3.3.2 組込みリソースの置換

パッケージ化ツールは、組込みリソースに戻す前にクラス・パスでカスタマイズされたリソースを検索します。Javaパッケージャには、デフォルトでクラス・パスに追加された"." (現在の作業ディレクトリ)があります。そのため、アプリケーション・アイコンを置き換えるには、javapackagerが実行されるディレクトリ(通常はルート・プロジェクト・ディレクトリ)の./package/macosx/DemoApp.icnsにカスタム・アイコンをコピーします。

タスク定義がロードされると、Java Antタスクのクラス・パスが定義されます。パスant-javafx.jarの前のルックアップに追加のパスを追加する必要があります。

例7-4は、クラス・パスに"."を追加する方法を示しています。コードの詳細な例は、例6-1を参照してください。

カスタマイズ化されたリソースを指定した後、冗長ビルド出力は、リソースが使用されていることをレポートします。たとえば、アプリケーションにカスタム・アイコンを追加した場合、例7-5に示すように、冗長出力はその追加内容をレポートします。

7.3.4 カスタマイズのオプション

自己完結型アプリケーション・パッケージをカスタマイズするには、既存のJava Ant要素の多くが使用されます。異なるパッケージには異なるパラメータ・セットが必要で、同じ要素が異なる役割を持つ場合があります。表7-1に、カスタマイズ・オプションの大部分を紹介します。

表7-1 Ant要素および属性を使用したカスタマイズ・オプション

要素 属性 詳細

<fx:application>

id

アプリケーション識別子。形式は、プラットフォームおよびパッケージ固有です。指定しない場合、値が生成されます。


version

アプリケーションのバージョン。デフォルトは1.0です。


name

アプリケーションの短縮名。ほとんどのバンドラでは、出力パッケージの名前の作成にこの名前を使用します。指定しない場合、メイン・クラスの名前が使用されます。

<fx:preferences>

shortcut

デスクトップ・ショートカット要求。trueに設定した場合、デスクトップ・ショートカットが要求されます。


menu

メニュー・エントリ要求。trueに設定した場合、アプリケーション・メニューのエントリが要求されます。


install

インストールの範囲。trueの場合、システム全体のインストールが要求されます。falseの場合、ユーザー・レベルのインストーラが要求されます。ほとんどのパッケージャでは、デフォルトでtrueになります。詳細は、7.4項「インストール可能なパッケージ」を参照してください。

<fx:fileset>

type

自己完結型アプリケーション・パッケージを構築するプロセスにおけるファイルの役割。タイプjnlpおよびnativeのリソースは、自己完結型アプリケーション・パッケージのビルドに使用されません。タイプlicenseのリソースは、クリックスルー・ライセンスまたはパッケージに埋め込まれたライセンスのコンテンツのソースとして使用されます。

<fx:info>

title

アプリケーション・タイトル。


vendor

アプリケーション・ベンダー。


category

アプリケーション・カテゴリ。カテゴリ名はパッケージ形式固有です。


license

ライセンス・タイプ(たとえばGPL)。この属性はLinuxバンドルでのみ使用されます。


copyright

短いコピーライト文。


description

アプリケーションの説明。

<fx:argument>


起動時にアプリケーションに渡される引数。

<fx:association>


アプリケーションに関連付けるファイルのタイプ。

<fx:jvmarg>


JVMに渡され、アプリケーションの実行に使用されるJVM引数(たとえば大きいヒープ・サイズなど)。

<fx:jvmUserArg>


JVMに渡され、アプリケーションの実行に使用される、ユーザー変更可能なJVM引数。詳細は、5.8.2.1項「ユーザーJVM引数の指定」を参照してください。

<fx:property>


アプリケーションを実行するJVMで設定されるプロパティ。


7.3.5 基本パッケージのプラットフォーム固有のカスタマイズ

自己完結型アプリケーション・パッケージの基本形式の作成およびカスタマイズは非常に簡単なプロセスですが、次の点に注意してください。

7.3.5.1 OS X

OS Xで生成されるパッケージは"application bundle"です。

いくつかの構成パラメータがアプリケーション・バンドルのInfo.plistファイルに配置され、次のルールに従う必要があります。

OS X 10.8ではGatekeeperが導入され、このコードがオブジェクティブCまたはJavaのどちらで実装されているかに関係なく、デフォルトで信頼されていないコードの実行を防ぎます。

ユーザーは実行するアプリケーションを手動で有効にできますが、これは完璧なユーザー操作ではありません。最適なユーザー操作を得るには、AppleからDeveloper ID証明書を取得します。Macバンドラでは、証明書を使用して.appフォルダに署名します。ローカル・ユーザー情報が証明書の名前と異なる場合、次の例に示すように、バンドル引数mac.signing-key-user-nameを設定する必要がある可能性があります。

詳細は、Apple DeveloperサイトのDeveloper IDおよびGatekeeperに関するトピックを参照してください。

7.3.7 ファイルと自己完結型アプリケーションの関連付け

アプリケーションのファイルの関連付けを登録するように自己完結型アプリケーションのインストーラを設定できます。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>

7.3.8 複数のエントリ・ポイントのサポート

自己完結型アプリケーションのパッケージを構築して、複数のエントリ・ポイントを持つ製品スイートをサポートできます。各エントリ・ポイントには独自のショートカットまたはアイコンがあります。<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>

7.4 インストール可能なパッケージ

配布を簡略化するために、自己完結型アプリケーションをプラットフォーム固有のインストール可能なパッケージにラップすることができます。サード・パーティ製ツールの可用性に応じて、Javaパッケージ化ツールでは、いくつかの形式のインストール可能なパッケージの組込みサポートが提供されています。

この章の他の項で説明されているように、インストール・プロセスのユーザー操作の調節は、特定のインストーラ・テクノロジに固有です。ただし、必要なインストーラのタイプを決定する必要があります。その決定に役立つ考慮事項は次のとおりです。

  • システム全体のインストールとユーザーごとのインストールのどちらですか。

    システム全体のインストールの結果、パッケージが共有の場所にインストールされ、システム上のどのユーザーも使用できるようになります。通常は管理権限が必要で、インストール・プロセス中は、高いインストーラ権限を承認するOSプロンプトなど、追加のステップが必要になると考えられます。

    ユーザーごとのインストールでは、パッケージをプライベート・ユーザー・ディレクトリにコピーし、管理権限は必要ありません。このタイプのインストールでは、できるだけ少ないダイアログを表示することができ、ユーザーに管理権限がなくてもプログラムを実行できます。

    ユーザー・レベルまたはシステム・レベルのインストール可能なパッケージが要求されるたびに、ビルド手順自体には管理権限は必要ありません。

  • クリックスルー・ライセンスが必要ですか。

    一部のインストール可能なパッケージでは、インストールの開始前にライセンス・テキストの表示をサポートしています。インストール・プロセスは、ユーザーがライセンスを受け入れた後にのみ開始します。

  • どのメニューとデスクトップの統合が必要ですか。

    ユーザーは、アプリケーションを容易に起動できる必要があります。そのため、デスクトップのショートカットを配置したり、メニュー内のアプリケーションのリストにアプリケーションを追加することが必要です。

現在の実装には、簡略化するための多くの前提があります。たとえば、インストーラは、パッケージをインストールする場所を選択するようユーザーに要求することはありません。開発者も、インストール場所の制御は限られており、システム全体またはユーザーごとのインストールのみ指定できます。

デフォルトの前提ではニーズを満たさない場合、構成ファイル・テンプレートを調整する(7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」を参照)か、基本的な自己完結型アプリケーションをパッケージ化してからそれをインストール可能なパッケージに自分でラップすることにより、詳細なカスタマイズが可能になります。

次のインストール可能なパッケージ形式がサポートされています。

7.4.1 EXEパッケージ

EXEパッケージを生成するには、Inno Setup 5以降をインストールし、PATHで使用可能にする必要があります。使用可能であることを検証するには、ビルドを起動するコマンド行またはビルド・スクリプトからiscc.exeの実行を試行します。

デフォルトでは、生成されたパッケージには次の特性があります。

  • 管理権限は必要ありません。

  • 最少のダイアログ数になるよう最適化されます。

  • プログラム・メニューまたはデスクトップ・ショートカット、あるいはその両方から参照されます。

  • インストールの終わりにアプリケーションを起動します。

図7-2は、Windows上にインストール中の自己完結型JavaFXアプリケーションの一般的なダイアログ・ボックスを示しています。

カスタマイズのヒント:


注意:

生成されたパッケージがインストールされたアプリケーションのリストに表示されている間は、Windowsインストーラ(MSI)テクノロジは使用されず、GUIDを使用する必要はありません。詳細は、Inno SetupのFAQを参照してください。

7.4.2 MSIパッケージ

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のドキュメントを参照してください。

7.4.3 DMGパッケージ

デフォルトでは、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に示すようなコンテンツがあります。

DMGインストーラは、テキスト形式で提供されたクリックスルー・ライセンスもサポートしています。リッチ・テキスト形式の使用が必要な場合、license.plistファイルを外部で準備し、7.3.3項「ドロップイン・リソースを使用したパッケージのカスタマイズ」で説明されている技術を使用してパッケージに追加します。

DMGパッケージを作成するには、サード・パーティ製ツールは必要ありません。

7.4.4 Linuxパッケージ

Linuxのインストール・パッケージの生成では、インストール・パッケージのビルドに必要なネイティブ・ツールがインストールされていることを前提としています。RPMパッケージの場合、通常、これはRPMBuildパッケージおよびその依存を意味します。DEBパッケージの場合、dpkg-debおよび依存が必要です。

パッケージをビルドするには、管理権限は必要ありません。

デフォルトでは、生成されたパッケージには次の特性があります。

  • アプリケーションを/optディレクトリにインストールします。

  • ショートカットをアプリケーション・メニューに追加します。

  • Linuxパッケージの通常の動作であるインストール用のUIはありません。

カスタマイズのヒント:

7.5 デプロイメント・シナリオの処理

次の特性を持つ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>タスクの例を示しています。

目次      

Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved.