デフォルトのビルド記述子

デフォルトのビルド記述子の階層により、生成プロセスがさらに柔軟になります。

次のレベルでデフォルトのビルド記述子を指定できます。

ビルド記述子を指定する方法については、デフォルトのビルド記述子の設定を参照してください。

デフォルトのビルド記述子の階層

「生成」ウィザードを使用してデフォルトのビルド記述子をオーバーライドしない限り、すべての EGL 生成操作が、生成中のパーツに対して指定されたデフォルトのビルド記述子を使用します。「生成」ウィザードを使用するには、EGL ソース・ファイルを右クリックし、「ウィザードを使用して生成」をクリックします。

使用するデフォルトのビルド記述子を決定するために、EGL は生成中のパーツのソース・ファイルから検索を開始し、ビルド記述子の最初のインスタンスが見つかるまでディレクトリー構造を上に移動します。

プロジェクトを作成するときに、EGL は projectName.eglbld ビルド・ファイルを提供し、このファイル内に 1 つ以上のビルド記述子パーツを定義します。 各タイプのプロジェクトに対して、EGL はこのファイルから取得された特定のデフォルトのビルド記述子をプロジェクト・レベルでのデフォルトのビルド記述子として指定します。
  • Rich UI プロジェクトの場合、EGL は projectNameJavaScriptBuildOptions ビルド記述子パーツを指定します。
  • 一般プロジェクトの場合、EGL が指定するビルド記述子パーツは、プロジェクトを作成するときに選択する「ターゲット・ランタイム・プラットフォーム」によって異なります。
    • Java™ の場合、projectNameJavaBuildOptions
    • COBOL の場合、projectNameCOBOLBuildOptions
  • Web プロジェクトまたはプラグイン・プロジェクトの場合、EGL は projectNameJavaBuildOptions ビルド記述子パーツを指定します。
注: EGL はこれらのデフォルト値を最初に指定しますが、ユーザーがそれらを削除できます。ユーザーがそれらを削除し、カスタムなデフォルトのビルド記述子を下位レベルで指定しない場合、EGL は解決のためにワークベンチ (設定) レベルを検索する必要があります。ワークベンチ・レベルでカスタムなデフォルトのビルド記述子が指定されていない場合、エラーになり、生成は失敗します。

EGL がデフォルトのビルド記述子を解決する方法の詳細については、このトピックの『ビルド記述子、ターゲット・プラットフォーム、およびデバッガー』、および例を参照してください。

ビルド記述子、ターゲット・プラットフォーム、およびデバッガー

さまざまな状況に対してさまざまなデフォルトのビルド記述子を指定できます。 デフォルトのビルド記述子には次の 2 つのカテゴリーがあります。
  • デバッグ
  • ターゲット・プラットフォーム
デバッグの場合、開発中のアプリケーションのタイプに応じて異なるデフォルトのビルド記述子を指定します。
  • EGL は、Java または COBOL に対して生成されるパーツには「解釈」デバッガーを使用します。このデバッガーは、EGL ソース・コードを解釈することにより機能します。
  • EGL は、JavaScript に対して生成されるパーツには JavaScript デバッガーを使用します。 このデバッガーは、ブラウザーで生成コードを実行することにより機能します。
EGL コードを生成できるターゲット・プラットフォームに基づいて、さまざまなデフォルトのビルド記述子を指定します。
  • COBOL
  • Java
  • JavaScript

カテゴリー内では、特定のレベルで値が指定されない場合、すべての値がそのレベルで使用されます。この規則は、EGL がターゲット・プラットフォーム・カテゴリーでビルド記述子を検索していて、任意のレベルで一致が見つかった場合、上位レベルでさらにビルド記述子パーツの検索を続行しないことを意味します。

例 1: クライアントとサーバーの両方に対するライブラリーの生成

Java と JavaScript の両方に対して同じライブラリーを生成し、そのライブラリーをクライアントとサーバーの両方で実行できるようにすることができます。Rich UI プロジェクトの例を以下に示します。
UIProject  <- JavaScript のデフォルトのビルド記述子 (システム)
  EGLSource
    ハンドラー
      
      MyHandler.egl
    ライブラリー
      MyLibrary.egl
    UIProject.eglbld
  ...

このプロジェクトは Rich UI 用にカスタマイズされているため、プロジェクト作成時に EGL によって JavaScript ターゲット・プラットフォーム用のプロジェクト・レベルのデフォルトのビルド記述子が指定されています。MyLibrary.egl について Java 生成と JavaScript 生成の両方を使用できるようにするには、ライブラリーに対して Java と JavaScript の両方のデフォルトのビルド記述子を指定します。

次の画面取りは、MyLibrary.egl ファイルを含む libraries フォルダーのプロパティーとして指定されたそれらのビルド記述子パーツを示しています。いずれかの値が指定されている場合は特定のレベルですべての値が使用されるという規則があるため、両方を指定する必要があります。
Java と JavaScript に対してターゲット・システム・ビルド記述子を設定。
以下に、更新されたプロジェクトの内容のリストを示します。
UIProject  <- JavaScript のデフォルトのビルド記述子 (システム)
  EGLSource
    ハンドラー
      
      MyHandler.egl
    ライブラリー  <- Java および JavaScript のデフォルトのビルド記述子 (ユーザー)
      MyLibrary.egl
    UIProject.eglbld
  ...
EGL では、デフォルトのビルド記述子を以下のように解決します。
  • MyLibrary.egl ライブラリーの場合、EGL はソース・ファイルから始めてパッケージ・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は Java と JavaScript 両方のカスタムなデフォルトのビルド記述子を検出します。注意して Java と JavaScript に互換性がある EGL タイプのみをソース・ファイルで使用した場合、EGL は両方のバージョンのライブラリーを生成します。
  • MyHandler.egl ファイルの場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は JavaScript のシステム・デフォルト・ビルド記述子を検出し、.js ファイルを生成します。.js ファイルは、デプロイメント中に HTML ファイルに埋め込まれます。

例 2: 生成障害

この例は、指定するデフォルトのビルド記述子オプションのレベルが高すぎる場合に何が発生するかを示しています。前の例と同じ状況を想定すると、Java のデフォルトのビルド記述子をプロジェクト・レベルに配置できます。
           <- JavaScript のデフォルトのビルド記述子 (システム)
UIProject  <- Java のデフォルトのビルド記述子 (ユーザー)
  EGLSource
    ハンドラー
      
      MyHandler.egl
    ライブラリー
      MyLibrary.egl
    UIProject.eglbld
  ...
EGL では、デフォルトのビルド記述子を以下のように解決します。
  • MyLibrary.egl の場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動し、そこで Java (カスタム) と JavaScript (システム) の両方に対するデフォルトのビルド記述子を検出します。EGL は、前の場合と同様に、両方のバージョンのライブラリーを生成します。
  • MyHandler.egl の場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動し、そこで Java と JavaScript の両方に対して同じデフォルトのビルド記述子を検出します。Rich UI ハンドラーを Java として生成できないため、エラーで終了します。

例 3: 同じプロジェクトでの UI とサービスの生成

パッケージ・レベルでカスタムなデフォルトのビルド記述子を作成し、Java 生成を管理します。 このプロジェクトには、ライブラリーではなく専用サービスが含まれています。
UIProject  <- JavaScript のデフォルトのビルド記述子 (システム)
  EGLSource
    ハンドラー
      
      MyHandler.egl
    サービス  <- Java のデフォルトのビルド記述子 (ユーザー)
      MyService.egl
    UIProject.eglbld
  ...
EGL では、デフォルトのビルド記述子を以下のように解決します。
  • MyService.egl サービスの場合、EGL はソース・ファイルから始めてパッケージ・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は Java のカスタムなデフォルトのビルド記述子を検出し、Java サービスを生成します。
  • MyHandler.egl ファイルの場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は JavaScript のシステム・デフォルト・ビルド記述子を検出し、.js ファイルを生成します。

例 4: 別々のプロジェクトでの UI とサービスの生成

Rich UI ハンドラーとサービスを別々のプロジェクトに配置することにより、デフォルトのビルド記述子全体をカスタマイズすることを回避できます。次のダイアグラムでは、UIProject は前と同様に Rich UI プロジェクトで、ServiceProject は一般プロジェクトです。
ServiceProject  <- Java のデフォルトのビルド記述子 (システム)
  EGLSource
    サービス
      
      MyService.egl
    ServiceProject.eglbld
  ...
UIProject  <- JavaScript のデフォルトのビルド記述子 (システム)
  EGLSource
    ハンドラー
      
      MyHandler.egl
    UIProject.eglbld
  ...
EGL では、デフォルトのビルド記述子を以下のように解決します。
  • MyService.egl ファイルの場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は Java のシステム・デフォルト・ビルド記述子を検出し、Java サービスを生成します。
  • MyHandler.egl ファイルの場合、EGL はソース・ファイルから始めてプロジェクト・レベルに達するまでディレクトリー構造を上に移動します。そのレベルで、EGL は JavaScript のシステム・デフォルト・ビルド記述子を検出し、.js ファイルを生成します。

マスター・ビルド記述子およびビルド記述子チェーン

システム管理者がマスター・ビルド記述子 の使用を必要とする可能性があります。この種のビルド記述子は、オーバーライドできず、EGL のインストールで発生するすべての生成で有効な情報を指定します。 システム管理者は、そのパーツが含まれている EGL ビルド・ファイルと併せて、 そのパーツを名前で指定します。マスター・ビルド記述子を設定する方法については、マスター・ビルド記述子の設定を参照してください。

生成固有のビルド記述子からビルド記述子のチェーンを作成して、チェーン 内の最初のビルド記述子が処理されてから 2 番目のビルド記述子が処理され、2 番目のビルド記述子が処理され てから 3 番目のビルド記述子が処理されるようにすることができます。所定のビルド記述子を定義するときは、nextBuildDescriptor ビルド記述子オプションに値を割り当ててチェーンを開始 (または継続) します。 システム管理者は同じ技法を使用してマスター・ビルド記述子からチェーンを作成 できます。チェーニング情報の意味については後述します。

ビルド記述子によって参照されるビルド・パーツは、参照ビルド記述子に可視 であることが必要です。例えば、リンケージ・オプション・パーツ、リソース関連パーツ、または次のビルド記述子などをビルド・パーツにすることができます。

オプションの優先順位

任意のビルド記述子オプションにおいて、生成時に最初に処理される値が有効 なままになります。全体の優先順位は次のようになります。
  1. マスター・ビルド記述子
  2. 生成時に指定したオーバーライド値を含む特定のビルド記述子オプション (「ウィザードを使用して生成」メニュー・オプションを使用している場合)。 ただし、これらのオプションで、マスター・ビルド記述子に設定された値をオーバーライドすることはできません。
  3. 生成固有のビルド記述子。このビルド記述子から拡張されたチェーン が後に続きます。
  4. マスター・ビルド記述子から拡張されたチェーン
この方式は次の点で有用です。
  • システム管理者は、マスター・ビルド記述子を設定することによって不変の値を指定できます。
  • 生成固有のビルド記述子を使用して、特定の生成に固有な値を割り当てることができます。
  • プロジェクト・マネージャーは、1 つ以上のビルド記述子をカス タマイズすることによってデフォルトのセットを指定できます。 通常このような場合、生成固有 のビルド記述子は、プロジェクト・マネージャーによって開発されたチェーン内の最 初のビルド記述子を指します。 デフォルト・オプションは、生成方法や準備方法が同様の一連のプログラムを開発す るときに便利です。
  • システム管理者は、マスター・ビルド記述子から拡張されたチェーン を設定することにより、一般的なデフォルトのセットを作成できます。 この機能を使用することは稀です。
  • 宛先ユーザー ID またはパスワードなど特定のビルド記述子オプションをオーバーライドする必要がある場合は、異なるビルド記述子パーツをセットアップすることなく、それを行うことができます。

所定のビルド記述子が複数回使用される場合、そのビルド記述子の最初のア クセスのみが有効になります。また、特定のオプションについては最初の指定のみが有効になります。

例 5: ビルド記述子チェーン

マスター・ビルド記述子に仮のオプションと値のペアが含まれていると 仮定します。

  OptionX                02
  OptionY                05

この例で、生成固有のビルド記述子 (myGen) には、以下のようなオプションと 値のペアが含まれています。

  OptionA                20
  OptionB                30
  OptionC                40
  OptionX                50

myGen で示されているように次のビルド記述子は myNext01 であり、以下のペアを含 んでいます。

  OptionA                120
  OptionD                150
myNext01 で示されているように次のビルド記述子は myNext02 であり、以下のペアを 含んでいます。
  OptionB                220
  OptionD                260
  OptionE                270

マスター・ビルド記述子で示されているように次のビルド記述子は myNext99 であり、以下のペアを含んでいます。

OptionW                  myUserID
OptionZ                  99

EGL は以下の順序でオプション値を受け入れます。

  1. マスター・ビルド記述子のオプションの値は以下のようになります。
      OptionX             02
      OptionY             05

    これらのオプションは、他のオプションをすべてオーバーライドします。

  2. 生成固有のビルド記述子 myGen の値は次のようになります。
      OptionA             20
      OptionB             30
      OptionC             40

    myGen の OptionX の値は無視されました。

  3. myNext01 および myNext02 のその他のオプションの値は次のようになり ます。
      OptionD             150
      OptionE             270

    myNext01 の OptionA の値は無視されました。myNext02 の OptionB および optionD の値も同 様に無視されました。

  4. myNext99 のその他のオプションの値は次のようになります。
     OptionW             myUserID
     OptionZ              99

  5. また、生成ウィザードを使用している場合は、デプロイメントのために生成出力の準備を行うシステムで、宛先ユーザーの ID およびパスワードなど、特定のビルド記述子オプションをオーバーライドするようにすることができます。 例えば、myNext99 の OptionW が destUserID ビルド記述子オプションで、かつ、生成ウィザードを使用している場合は、 生成時に OptionW の値を設定または変更することができます。

フィードバック