バージョン 7 より前のバージョンからマイグレーションする場合は、EGL V7.0 マイグレーション・ツールを使用してバージョン 7.5 に直接マイグレーションできます。
バージョン 7.5 以降からのマイグレーション
バージョン 7.5 からバージョン 8.0 に移行する場合、マイグレーション・ツールの実行を必要としませんが、以下の事項に注意してください。
- プロジェクトのディレクトリー構造はバージョン 8 で変更されました。
バージョン 8.0 の EGL では、生成された Java コードは新しい EGLGen/JavaSource ディレクトリーに格納されます。これは、プロジェクト・ディレクトリー構造の最上位のディレクトリーです。EGL は、ユーザーが生成するたびに (のクリックも含む)、このコードを更新します。
手動で変更した Java コードには、最上位の JavaSource ディレクトリーを使用します。「クリーン」コマンドでは、このディレクトリーは操作されません。
Rich UI プロジェクトでは、デバッグまたは実行時使用のいずれの目的で生成するかを判別するために生成モード設定を使用することがなくなりました。代わりに、この両方のタイプのコードは、それぞれ EGLGen/JavaScript/Debug ディレクトリーと EGLGen/JavaScript/Target ディレクトリーに自動的に生成されます。
バージョン 7 のディレクトリー構造を維持する場合、バージョン 8 でもプロジェクトは適切に機能します。ディレクトリー構造をバージョン 8 の新しい構造に更新すると、バージョン 7 でそのプロジェクトを使用できなくなります。
この変更があるため、開発者が Java™ 生成用に別のプロジェクトを作成して単一のデプロイ済みプロジェクトにマージする可能性が高くなります。これらのプロジェクトに相互依存関係がある場合は、Java ビルド・パスの変更が必要な可能性があります。詳しくは、Java ビルド・パスを参照してください。
- Rational® Business Developer バージョン 8 は Java 5 以降を必要とします。このトピック内の『Rational Business Developer バージョン 8 での Java に関する考慮事項』を参照してください。
- JavaScript 用に生成する場合、EGL NUMBER loose type の内部表現は新しくなります。
EGL のデフォルトの動作は、EGL ファイルを最初にバージョン 8 に移行したときに自動的に JavaScript を再生成することであるため、ほとんどの場合アクションは不要です。JavaScript に対して「ビルド後の生成」設定を使用不可に設定した場合は、バージョン 8 で使用する前に NUMBER 型を含む JavaScript ファイルをすべて手動で生成する必要があります。詳しくは、loose typeおよび生成設定の変更を参照してください。
- 新規バージョンに移行するときのベスト・プラクティスは、新規ワークスペースを作成することです。
- EGL Rich UI を使用していて、バージョン 8 に移行するときにウィジェット・ライブラリーを更新しない場合、互換性の問題が発生する可能性があることに注意してください。
詳しくは、このトピックの『ウィジェット・ライブラリーの既知の互換性』を参照してください。
Rational Business Developer バージョン 8 での Java に関する考慮事項
バージョン 8 は Java 5 (バージョン 1.5.0 とも呼ばれる) 以降を必要とします。この要件は、Java バージョン 1.4.0 を必要としたバージョン 7 からのアップグレードです。バージョン 8 には、Java 6 の Java Runtime Environment (JRE) が組み込まれています。
この JRE には EGL の以前のバージョンで生成されたコードと完全な互換性があり、新規 JRE のために既存の EGL プログラムを再生成する必要はありません。
EGL を使用しているときに、Java バッチ・プログラムおよび Tomcat サーバーを製品とともにインストールされた JRE で実行することを選択できます。
システム上にインストールされているその他の Java 5 以上の任意の JRE でそれらのバッチ・プログラムを実行することも選択できます。ただし、WebSphere® Application Server の JRE は除きます。
その JRE はその製品専用で使用されます。また、EGL または WebSphere Application Server の外部にデプロイする生成コードを実行するための JRE も必要です。
この目的には、Java 5 以降の任意の JRE を選択できます。
ほとんどの場合、この変更によって発生する問題はありません。ただし、Java 1.4 の企業標準にこだわる場合は、バージョン 8 にマイグレーションしないでください。
ウィジェット・ライブラリーの既知の互換性
Rich UI プロジェクトをバージョン 8 に移行するときのベスト・プラクティスは、それらのプロジェクトのウィジェット・ライブラリーを最新レベルに更新することです。これらのプロジェクトをインポートする方法については、製品提供のプロジェクトのインポートを参照してください。
以前のリリースからのウィジェット・ライブラリーを使用することを選択する場合は、ライブラリーの特定の組み合わせのみがテストされていることに注意してください。次の表に、互換性があることがわかっているウィジェット・ライブラリーのバージョンを示します。その他の組み合わせも考えられますが、共に使用した場合に効率的に機能するとは保証されません。
表 1. 互換性があることがわかっているウィジェット・ライブラリー| 製品バージョン |
Rich UI ウィジェット |
Dojo ウィジェット |
Dojo ランタイム |
| 8.0 |
2.0.0 |
1.0.0 |
1.5 |
| 7.5.1.5 |
1.0.3 |
0.8.0* |
1.4 |
| 7.5.1.4 |
1.0.2 |
0.7.1* |
1.3.2 |
| 7.5.1.3 |
1.0.1 |
該当なし |
該当なし |
| 7.5.1.2 以前 |
1.0.0 |
該当なし |
該当なし |
* 公式には非サポート。EGL Café を介して配布。
バージョン 7.1 からバージョン 7.5 より前のバージョンへのマイグレーション
製品を開始すると、すべてのプロジェクトを検査して、マイグレーションが必要であるかどうかが確認されます。この検査は、プロジェクトをインポートするときや、ソース・コード・マネージャーの外部で
プロジェクトを検査するときにも実行されます。マイグレーションが必要な場合は、ワークスペースにメッセージが表示されます。その後、マイグレーションする具体的なプロジェクトおよびリソースを
選択できます。
EGL バージョン 7.1 から 7.5 にマイグレーションするには、以下のコード変更が複数のファイルまたはプロジェクトに必要です。
- ExternalType 関数パラメーターに in 修飾子が必要です。
- Apache .jar ファイルのパスが変更されました。
- BIRT レポート・ファイルには ICU4J (International Components for Unicode for Java) サポートが必要です。
バージョン 7.0 からバージョン 7.1 より前のバージョンまでへのマイグレーション
バージョン 7.0 からバージョン 7.1 までへのマイグレーションを自動化するプログラムはなく、ほとんどの場合、マイグレーションは不要です。
マイグレーションは、次の 2 つの場合に必要です。
- フォームを使用していて、V7 へマイグレーションした場合、コードを変更してから、V7.1 を実行する必要があります。
EGL バージョン 7 ではフォームがサポートされていないため、
フォームを使用するユーザーのほとんどはバージョン 7 へマイグレーションしませんでした。
EGL V7 から V7.1 へフォームをマイグレーションするには、
以下の変更を行います。
- すべての printFloatingArea プロパティーおよ
び screenFloatingArea プロパティーに @ 演算子を追加します。
- フォームの @printFloatingArea 複合プロパティーすべてを、新規の printFloatingAreas プロパティー内に配置します。
- フォームの @screenFloatingArea 複合プロパティーすべてを、新規の screenFloatingAreas プロパティーに配置します。
- バージョン 7.0 から 7.0.0.3 まで用に生成された Web プロジェクトで作業し、そのコード
が WebSphere Application Server で実行され、すべてのプラットフォーム上の Web サービスにアクセスする場合は、プロジェクトを変更する必要があります。
プロジェクトが、WebSphere Application Server 以外のサーバーで稼働する場合、変更は不要です。
WebSphere Application Server を使用する Web プロジェクトを EGL V7.0 から V7.1 にマイグレーションするには、次のステップを実行します。
- 関連付けられた EAR ファイルにある WAR ファイルのクラス・ローダーを
、PARENT_FIRST に切り替えます。
- Web プロジェクトのルートにある projectNameEAR デプロイメント記述子をダブルクリックします。ここで projectName はプロジェクト名です。このデプロイメント記述子
は J2EE デプロイメント記述子であり、EGL デプロイメント記述子ではありません。
- デプロイメント記述子エディターで、「デプロイメント」タブをクリックします。
- 「デプロイメント」ページの下部で、「アプリケーション」セクションを見つけます。
- 「アプリケーション」リストで、Web プロジェクトを表す WAR ファイルを選択します。
- 「クラス・ローダー・モード」リストで、「PARENT_FIRST」を選択します。
- デプロイメント記述子を保存して、閉じます。
- 「リソース」パースペクティブを開き、以下の .jar ファイル
を projectName/WebContent/WEB-INF/lib から削除します。
- axis.jar
- commons-discovery-0.2.jar
- commons-logging-1.0.4.jar
- eglwsdl.jar
- jaxrpc.jar
- saaj.jar
- wsdl4j-1.5.1.jar
- プロジェクトを再生成して、ServerType ビルド記述子オプションが、WebSphere Application Server の適切なバージョンに設定されていることを確認します。
COBOL ソース・プロジェクトまたは Rich UI プロジェクトをマイグレーションする場合は、
さらに変更を行わなければならないことがあります。詳しくは、『COBOL から EGL へのマイグレーション』および『Rich UI プロジェクトのマイグレーション』を参照してください。