Maven プラグインガイド



第1章 はじめに

1.1. Maven プラグインガイド

本ガイドはエンジニア、エンジニア、およびアプリケーションに Migration Toolkit(MTA)を使用して Java アプリケーションやその他のコンポーネントを移行するユーザーを対象としています。Maven プラグインのインストールおよび実行方法、生成されたレポートを確認し、追加機能を活用する方法を説明します。

1.2. MTC(Migration Toolkit for Applications)

MTC(Migration Toolkit for Applications)

Migration Toolkit for Applications(MTA)は、拡張可能かつカスタマイズ可能なルールベースのツールで、Java アプリケーションの移行を単純化します。

MTA は、プロジェクトソースディレクトリーおよびアプリケーションアーカイブを含むアプリケーションアーティファクトを検査し、変更を必要とする領域を強調表示する HTML レポートを生成します。MTA を使用すると、以前のバージョンの Red Hat JBoss Enterprise Application Platform または Oracle® WebSphere® Application Server などの他のコンテナーから Java アプリケーションを移行できます。

Migration Toolkit for Applications で移行を簡素化するにはどうすればよいですか?

アプリケーション向けの MTC(Migration Toolkit for Applications)は一般的なリソースを見つけ、アプリケーションの移行時に技術と既知の問題のある場所を強調表示します。この目的は、アプリケーションが使用するテクノロジーの概要を提供し、組織がエンタープライズアプリケーションを Java EE および Red Hat JBoss Enterprise Application Platform に推定、文書化、移行するために使用できる詳細なレポートを提供することです。

詳細を確認する方法

MTC(Migration Toolkit for Applications)の機能、サポートされる設定、システム要件、および利用可能なツールの詳細は、『 スタートガイド』 を参照してください。

1.3. Maven プラグインについて

MTC(Migration Toolkit for Applications)の Maven プラグインは Maven ビルドプロセスに統合され、開発者はソースコードの各反復を使用して移行およびモダライゼーションを継続的に評価できます。分析結果を強調表示するレポートが多数提供され、ビルドごとに更新が必要な開発者向けに設計されています。

第2章 Getting Started (スタートガイド)

2.1. 前提条件

Maven プラグインを使用する前に、以下の前提条件を満たしていることを確認してください。

  • Java Platform、JRE バージョン 8+
  • 最小 4 GB のメモリー、8 GB 推奨
  • Maven バージョン 3.2.5 以降
注記

macOS を実行している場合は、ユーザープロセスの最大数、少なくとも、をに maxproc、オープンファイルの最大数 2048を設定 maxfilesすることが推奨され 100000ます。

2.2. Maven プラグインの実行

Maven プラグインは、アプリケーションの内にプラグインへの参照を含めることで実行され pom.xmlます。アプリケーションがビルドされると、Maven プラグインが実行され、分析用のレポートが生成されます。

Maven プラグインを実行するには、以下の手順を実行します。

  1. アプリケーションのに以下のプラグインを追加し pom.xmlます。

    [...]
    <plugin>
        <groupId>org.jboss.windup.plugin</groupId>
        <artifactId>windup-maven-plugin</artifactId>
        <version>4.1.0.Final</version>
        <executions>
            <execution>
                <id>run-windup</id>
                <phase>package</phase>
                <goals>
                    <goal>windup</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <offlineMode>true</offlineMode>
            <windupVersion>4.1.0.Final</windupVersion>
        </configuration>
    </plugin>
    [...]
    • offlineMode: オフラインモードで実行し、ネットワーク機能を無効にしてパフォーマンスを向上させます。
    • windupVersion: MTA のバージョン。

      上記の例は、最低限必要な引数を示しています。利用可能なすべての引数 の詳細な説明は、「 MTA Maven 引数」を参照してください。

  2. プロジェクトをビルドします。

    $ mvn clean install
  3. 生成されたレポート にアクセスします。

2.3. 複数のモジュールを使用した Maven プラグインの実行

複数のモジュールを持つプロジェクトで Maven プラグインを使用するには、親の内に設定を配置し pom.xmlます。実行中、Maven プラグインは親モジュールおよび子モジュールの分析が含まれる単一のレポートを生成します。

注記

マルチモジュールプロジェクトで false に設定 inherited することが強く推奨されます。それ以外の場合は、各子がコンパイルされるときに Maven プラグインが実行されるため、子モジュールに対して Maven プラグインが複数実行されます。false inherited に設定すると、各プロジェクトが 1 度だけ分析され、実行時間が大幅に短縮されます。

複数のモジュールを持つプロジェクトで Maven プラグインを実行するには、以下の手順を実行します。

  1. 親プロジェクトのに以下のプラグインを含め pom.xmlます。親モジュールの例 pom.xml を以下に示します。

    <plugin>
        <groupId>org.jboss.windup.plugin</groupId>
        <artifactId>windup-maven-plugin</artifactId>
        <version>4.1.0.Final</version>
        <inherited>false</inherited>
        <executions>
            <execution>
                <id>run-windup</id>
                <phase>package</phase>
                <goals>
                    <goal>windup</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <input>${project.basedir}</input>
            <offlineMode>true</offlineMode>
            <windupHome>/PATH/TO/CLI/</windupHome>
            <windupVersion>4.1.0.Final</windupVersion>
        </configuration>
    </plugin>

    これ pom.xml により、Run the Maven Plugin の以下の属性が適用されます。

    • inherited: プラグインレベルで定義されるこの属性は、この設定を子モジュールで使用するかどうかを指定します。パフォーマンスを向上 false させるには、をに設定します。
    • input: 分析するプロジェクトが含まれるディレクトリーへのパスを指定します。この属性はデフォルトので {project.basedir}/src/main、親プロジェクトに分析するソースコードがない場合は定義する必要があります。
    • windupHome: MTA CLI の抽出したコピーへのパス。この属性は任意ですが、パフォーマンスを向上させることが推奨されます。

      上記の例は、推奨される引数のセットを示しています。利用可能なすべての引数 の詳細な説明は、「 MTA Maven 引数」を参照してください。

  2. 親プロジェクトをビルドします。ビルドプロセス中に、Maven プラグインは追加設定なしでプロジェクトのすべての子に対して実行されます。

    $ mvn clean install
  3. 完了したら、通常 通りに生成されたレポート にアクセスします。このレポートには、親およびすべての子に関する分析が含まれます。

2.4. レポートへのアクセス

MTC(Migration Toolkit for Applications)を実行すると、の outputDirectory 引数を使用してレポート OUTPUT_REPORT_DIRECTORY がに生成され pom.xmlます。ビルドが完了すると、ビルドログに以下のメッセージが表示されます。

Windup report created: OUTPUT_REPORT_DIRECTORY/index.html

output ディレクトリーには、以下のファイルおよびサブディレクトリーが含まれます。

OUTPUT_REPORT_DIRECTORY/
├── index.html          // Landing page for the report
├── EXPORT_FILE.csv     // Optional export of data in CSV format
├── graph/              // Generated graphs used for indexing
├── reports/            // Generated HTML reports
├── stats/              // Performance statistics

MTA レポートおよび移行またはモダライゼーション の作業を評価する方法については、『 MTA CLI ガイド』 の「レポートの確認」セクション を参照してください。

第3章 CSV 形式でのレポートのエクスポート

MTA には、分類やヒントなどのレポートデータをローカルファイルシステムのフラットファイルにエクスポートする機能があります。エクスポート機能は現在 CSV ファイル形式をサポートしており、レポートデータをコンマ(,)区切りでフィールドとして提示します。

CSV ファイルは、Microsoft Excel、OpenOffice Calc、LibreOffice Calc などのスプレッドシートソフトウェアでインポートおよび操作できます。スプレッドシートソフトウェアは、MTA レポートから結果データを並べ替え、分析、評価、および管理する機能を提供します。

3.1. レポートのエクスポート

レポートを CSV ファイルにエクスポートするには、exportCSV 引数をに設定された MTA を実行し trueます。

<exportCSV>true</exportCSV>

CSV ファイルは、outputDirectory 引数で指定されたディレクトリーに作成されます。

3.2. CSV ファイルの分割プログラムへのインポート

  1. スプレッドシートソフトウェア (例: Microsoft Excel) を起動します。
  2. FileOpen を選択します。
  3. CSV のエクスポートされるファイルを参照し、これを選択します。
  4. これで、データはスプレッドシートソフトウェアで分析できるようになりました。

詳細や問題の解決には、スプレッドシートソフトウェアに関するヘルプを確認してください。

3.3. CSV データ構造の概要

CSV 形式の出力ファイルには、以下のデータフィールドが含まれます。

ルール ID
指定の項目を生成したルールの ID。
問題のタイプ
ヒント または 分類
件名
classification または hint の件名。このフィールドは、特定のアイテムの問題を要約します。
説明
指定項目の問題の詳細な説明。
リンク
問題に関する追加情報を提供する URL。リンクは、リンクとリンクの説明という 2 つの属性で構成されます。
アプリケーション
このアイテムが生成されたアプリケーションの名前。
ファイル名
指定項目のファイルの名前。
ファイルパス
指定項目のファイルパス。
指定項目のファイルの行番号。
ストーリーポイント
特定のアイテムに割り当てられた、努力のレベルを表すストーリーポイントの数。

付録A リファレンス資料

A.1. Maven プラグイン引数

以下は、利用可能な MTA Maven プラグイン引数の詳細な説明です。

表A.1 MTA Maven プラグイン引数
引数説明

enableCompatibleFilesReport

Compatible Files レポートの生成を有効にするフラグ。問題が検出されない状態ですべてのファイルを処理するため、このレポートには大規模なアプリケーションの処理に時間がかかる場合があります。

enableTattletale

各アプリケーションの Tattletale レポートを生成するためのフラグ。

excludePackages

評価から除外するパッケージの一覧たとえば、「com.mycompany.commonutilities」と入力すると、パッケージ名が「com.mycompany.commonutilities」で始まるクラスをすべて除外します。

excludeTags

除外するタグの一覧。指定されている場合は、これらのタグを持つルールは処理されません。

explodedApps

指定された入力ディクショナリーに 1 つののアプリケーションのソースファイルが含まれていることを示すフラグ。詳細は、「 入力ファイルの引数テーブル 」を参照してください。

exportCSV

レポートデータをローカルファイルシステムの CSV ファイルにエクスポートするフラグ。MTA は、outputDirectory 引数で指定されたディレクトリーにファイルを作成します。CSV ファイルは、データの操作および分析のためにスプレッドシートプログラムにインポートできます。詳細は、「 CSV 形式のレポートをエクスポート」を 参照してください。

includeTags

使用するタグの一覧。指定されると、これらのタグを持つルールのみが処理されます。

inputDirectory

分析するアプリケーションが含まれるディレクトリーへのパスを指定します。この引数のデフォルトはです {project.basedir}/src/main/。詳細は、「 入力ディレクトリーの指定」を参照して ください。

keepWorkDirs

グラフデータベースや展開されたアーカイブなどの一時作業ファイルを削除しないように MTA に指示するフラグ。これはデバッグに役立ちます。

packages

MTA が評価するパッケージの一覧。この引数は必須です。詳細は「 パッケージの選択」を 参照してください。

offlineMode

フラグはオフラインモードで動作し、スキームの検証などのネットワークアクセス機能を無効にします。パフォーマンスの向上に使用します。

outputDirectory

MTA が生成したレポート情報を出力するディレクトリーへのパスを指定します。この引数のデフォルトはです {project.build.directory}/windup-report。詳細は、「 出力ディレクトリーの指定」を参照して ください。

overwrite

フラグ: で指定されている既存の出力ディレクトリーを強制的に削除し outputDirectoryます。デフォルトは true です。

警告

重要な情報が含まれるレポート出力ディレクトリーを指定しないでください。

sourceTechnologies

移行元となる 1 つ以上のソーステクノロジー、サーバー、プラットフォーム、またはフレームワークの一覧。この引数は、引数とともに使用されるルールセットを判断するのに targetTechnologies 役立ちます。詳細は、「 ソーステクノロジーの設定 」を参照してください。

sourceMode

評価するアプリケーションに、コンパイルされたバイナリーではなくソースファイルが含まれていることを示すフラグ。デフォルトは true です。詳細は、「 入力ファイルの引数テーブル 」を参照してください。

targetTechnologies

移行先の 1 つ以上のターゲットテクノロジー、サーバー、プラットフォーム、またはフレームワークの一覧。この引数は、引数とともに使用されるルールセットを判断するのに sourceTechnologies 役立ちます。詳細は、「 ターゲットテクノロジーの設定 」を参照してください。

userIgnorePath

MTA が無視されるファイルを識別する場所を指定します。

userRulesDirectory

カスタム MTA ルールを検索する場所を指定します。値は、単数または複数のルールセットファイルを含むディレクトリーです。ルールセットファイルは、.windup.xml またはの .rhamt.xml 接尾辞を使用する必要があります。

windupHome

抽出した MTA CLI のルートを参照する任意の引数。CLI のローカルインストールを参照すると、Maven プラグインはすべてのインデックスに直接アクセスできるため、パフォーマンスが向上します。

windupVersion

MTA のバージョンを指定します。

A.1.1. 入力ディレクトリーの指定

分析する 1 つ以上のアプリケーションを含むファイルまたはディレクトリーへのパス。デフォルトはです {project.basedir}/src/main/

Usage

<inputDirectory>INPUT_ARCHIVE_OR_DIRECTORY</inputDirectory>

inputDirectory 引数に提供される入力ファイルタイプがファイルまたはディレクトリーであるかどうかに応じて、提供される追加の引数に応じて、以下のように評価されます。

ディレクトリー
--explodedApp--sourceMode引数なし

ディレクトリーは 1 つのアプリケーションとして評価されます。

ディレクトリーは 1 つのアプリケーションとして評価されます。

各サブディレクトリーはアプリケーションとして評価されます。

ファイル
--explodedApp--sourceMode引数なし

引数は無視されます。ファイルは 1 つのアプリケーションとして評価されます。

ファイルは圧縮プロジェクトとして評価されます。

ファイルは 1 つアプリケーションとして評価されます。

A.1.2. 出力ディレクトリーの指定

MTA が生成したレポート情報を出力するディレクトリーへのパスを指定します。

使用方法

<outputDirectory>OUTPUT_REPORT_DIRECTORY</outputDirectory>

  • 省略すると、レポートが {project.build.directory}/windup-report ディレクトリーに生成されます。
  • 出力ディレクトリーが存在する場合は、overwrite 引数の値に基づいて上書きされます。この引数はデフォルトでに設定され true、MTA はディレクトリーを削除し、再作成します。

A.1.3. ソーステクノロジーの設定

移行元となる 1 つ以上のソーステクノロジー、サーバー、プラットフォーム、またはフレームワークの一覧。この引数は、引数とともに使用されるルールセットを判断するのに targetTechnologies 役立ちます。

Usage

<sourceTechnologies>
    <source>eap:6</source>
</sourceTechnologies>

sourceTechnologies 引数は、Maven のバージョン範囲の構文 に続くバージョンサポートを提供するようになりました。これにより、指定されたバージョンに一致するルールセットのみを実行するように MTA が指示されます。例: <source>eap:5</source>

A.1.4. ターゲット引数の設定

移行先の 1 つ以上のターゲットテクノロジー、サーバー、プラットフォーム、またはフレームワークの一覧。この引数は、引数とともに使用されるルールセットを判断するのに sourceTechnologies 役立ちます。この引数は必須です。

使用方法

<targetTechnologies>
  <target>eap:7</target>
</targetTechnologies>

targetTechnologies 引数は、Maven のバージョン範囲の構文 に続くバージョンサポートを提供するようになりました。これにより、指定されたバージョンに一致するルールセットのみを実行するように MTA が指示されます。例: <target>eap:7</target>

警告

JBoss EAP に移行する場合は、必ずターゲットでバージョンを指定してください(例:) eap:6。指定すると、移行パスに関連しないものも含め、すべてのバージョンの JBoss EAP の ruleset のみが実行 eap されます。

ソースプラットフォームに適した JBoss EAP バージョンについては、『 MTA Getting Started Guide』 の「 Supported Migration Paths 」を参照してください。

A.1.5. Packages の選択

MTA が評価するパッケージの一覧。この引数を使用することは強く推奨されます。

使用方法

<packages>
  <package>PACKAGE_1</package>
  <package>PACKAGE_2</package>
</packages>

  • ほとんどの場合、カスタムアプリケーションクラスパッケージの評価にのみ関心があり、標準のJava EE パッケージやサードパーティのパッケージには関心がありません。PACKAGE_N 引数はパッケージ接頭辞で、すべてのサブパッケージがスキャンされます。たとえば、パッケージ com.mycustomapp およびをスキャンするには com.myotherapp、で以下のスニペットを使用し pom.xmlます。

    <packages>
      <package>com.mycustomapp</package>
      <package>com.myotherapp</package>
    </packages>
  • などの標準の Java EE サードパーティーソフトウェアのパッケージ名を提供することはできますが org.apache、通常は移行に影響を及ぼさないので、パッケージ名を含めないことが推奨されます。

A.2. ルールのポイント

A.2.1. ポイントとは何ですか?

ストーリーポイント は、アジャイルソフトウェア開発で一般的に使用される抽象メトリクスで、機能や変更を実装するのに必要な 作業量 を予測します。

MTC(Migration Toolkit for Applications)は、特定のアプリケーションコンストラクトを移行するために必要な作業レベルを表現し、アプリケーションを全体として表します。必ずしも工数に変換される訳ではありませんが、この値はタスク全体で一貫性を持たせる必要があります。

A.2.2. ルールでのポイントの推定方法

ルールのストーリーポイントの作業レベルを見積もることは複雑です。以下は、ルールに必要な作業レベルを見積もる際に MTA が使用する一般的なガイドラインです。

作業レベルストーリーポイント説明

Information

0

移行の優先度が非常に低いか、優先度のない情報警告。

Trivial

1

移行は、些細な変更または単純なライブラリースワップであり、API の変更はないか、最小限となります。

Complex

3

移行タスクに必要な変更は複雑ですが、解決策が文書化されています。

Redesign

5

移行タスクでは、API が大幅に変更され、再設計または完全なライブラリーの変更が必要になります。

Rearchitecture

7

移行には、コンポーネントまたはサブシステムの完全な再アーカイブが必要です。

Unknown

13

移行ソリューションは不明なため、完全な再書き込みが必要になる場合があります。

A.2.3. タスクの影響

作業量レベルに加えて、移行タスクを分類してタスクの重大度を示すことができます。以下のカテゴリーは、タスクを完了する必要があるか、または延期される必要があるかを示します。

必須
移行を成功させるには、タスクを完了する必要があります。変更が行われないと、生成されるアプリケーションはビルドまたは実行に成功しません。たとえば、ターゲットプラットフォームでサポートされないプロプライエタリー API の置き換え例が含まれます。
任意
移行タスクが完了しない場合、アプリケーションは機能しますが、結果が最適ではない可能性があります。移行時に変更が行われない場合には、移行の完了直後にスケジュールすることが推奨されます。これには、EJB 2.x コードの EJB 3 へのアップグレードが挙げられます。

タスクの分類に関する詳細は、『ルール開発ガイド』「カスタムルールカテゴリーの使用」を参照してください。

A.3. 関連資料

A.3.1. Get Involved

MTC(Migration Toolkit for Applications)が、多くのアプリケーションコンストラクトおよびサーバー設定に対応するのに役立つようにするには、以下の項目のいずれかに役に立ちます。

  • jboss-migration-feedback@redhat.com にメールを送信し、MTA 移行ルールが対象とすべき内容をご連絡ください。
  • 移行ルールをテストするためのアプリケーションの例を指定します。
  • 移行が困難なアプリケーションコンポーネントおよび問題エリアを特定します。

    • これらの問題移行エリアについて簡単な説明を記入します。
    • 問題移行領域を解決する方法を説明する簡単な概要を記述します。
  • アプリケーションで Migration Toolkit for Applications を試行します。発生した 問題を必ず報告 してください。
  • Migration Toolkit for Applications ルールリポジトリーへの貢献。

    • Migration Toolkit for Applications ルールを記述して、移行プロセスを識別または自動化します。
    • 新規ルールのテストを作成します。
    • 詳細は、『ルール開発ガイド』を参照してください。
  • プロジェクトのソースコードへの貢献。

    • コアルールを作成します。
    • MTA のパフォーマンスまたは効率が向上します。
    • 環境の設定およびプロジェクトの設定方法に関する詳細は、『Core Development Guide』を参照してください。

あらゆるレベルの貢献が大きく評価されます。

A.3.3. 既知の MTA の問題

MTA の既知の問題は、Open MTA の問題 で確認できます。

A.3.4. MTA に関する問題の報告

MTC(Migration Toolkit for Applications)は、JIRA を課題追跡システムとして使用します。MTA の実行で問題が発生した場合は、JIRA Issue を作成してください。

注記

JIRA で問題を作成するために、すでに JIRA アカウントにサインアップする必要があります。

A.3.4.1. JIRA の問題の作成
  1. ブラウザーを開き、JIRA の Create Issue ページに移動します。

    ログインしていない場合は、ページの右上にある Log In リンクをクリックし、認証情報を入力します。

  2. 以下のオプションを選択し、Next ボタンをクリックします。

    • プロジェクト

      MTA のコアの問題には、Red Hat Application Migration Toolkit(↑DUP) を選択します。

      MTA ルールの問題については、Red Hat Application Migration Toolkit ルール(‍DUPRULE)を選択し ます。

    • Issue Type: Bug
  3. 次の画面では、以下のフィールドを入力します。

    • Summary: 問題または問題の簡単な説明を入力します。
    • Environment: オペレーティングシステム、Java のバージョン、およびその他の関連情報の詳細を指定します。
    • Description: 問題の詳細情報を指定します。ログと例外トレースを必ず含めてください。
    • Attachment: 問題を生じるアプリケーションまたはアーカイブに機密情報が含まれておらず、MTA 開発チームと共有する場合は、browse ボタンを使用して問題を添付します。
  4. Create ボタンをクリックして JIRA の問題を作成します。





改訂日時: 2020-10-18 19:16:58 AEST

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.