完璧な世界では、resolveタスクが収集してチェックするものは全部、開発プロセス中に機能するはずですが、実際には例外が生じて、resolveタスクのデフォルト機能の変更を強いられる場合もあります。ワークスペースのresolveタスクに慣れていない場合は、Resolving Your Modulesで詳細を参照してください。
リゾルバのチェックに合格するためにプロジェクトの変更が必要となる場合が開発中に発生してしまう可能性があるシナリオは、二通りあります。
- 一つは、対象のLiferay DXPインスタンスまたは現在のワークスペースで利用できないサードパーティのライブラリに依存している場合です。
- もう一つは、Liferay DXPのカスタマイズされたディストリビューションに依存している場合です。
ここでは、これらのユースケースについて、説明していきます。
Liferay DXPに含まれていないサードパーティのライブラリへの依存
デフォルトでは、resolveタスクはLiferay DXPの機能とワークスペースのモジュールの機能を全部収集します。ただし、モジュールがどちらのスペースにも含まれていないサードパーティのプロジェクト（例: Google Guava）に依存している場合は違います。プロジェクトがこのプロジェクトタイプに依存している場合、resolveタスクはデフォルトでは失敗します。このプロジェクトを実行時にデプロイして利用できるように計画していても、リゾルバにはそれが分かりません。したがって、これを回避するには、リゾルバをカスタマイズする必要があります。
これを行うには、以下の3つの方法があります。
サードパーティの依存関係エラーの解決方法については、Resolving Third Party Library Package Dependenciesのチュートリアルを参照してください。
モジュールにサードパーティのライブラリを埋め込む
サードパーティのプロジェクトに依存するモジュールが1つしかない場合は、モジュールにJARを埋め込むことでリゾルバの失敗を回避できます。OSGiコンテナ内の複数のプロジェクトがそのモジュールに依存している場合、この方法はベストプラクティスではありません。詳細については、Embedding Libraries in a Moduleのセクションを参照してください。
サードパーティのライブラリの機能を現在の静的なリゾルバ機能セットに追加する
サードパーティの依存関係を提供されたモジュールとしてリストすることにより、ターゲットプラットフォームのデフォルトの機能リストに追加することができます。これを行うには、ワークスペースのルートbuild.gradleファイルに、以下のGradleコードを追加します。
dependencies {
providedModules group: "GROUP_ID", name: "NAME", version: "VERSION"
}
たとえば、提供モジュールとしてGoogle Guavaを追加する場合は以下のようになります。
dependencies {
providedModules group: "com.google.guava", name: "guava", version: "23.0"
}
上記はリゾルバにサードパーティの依存関係を提供し、初期化（例: blade server init）をするとサードパーティの依存関係をダウンロードし、依存関係がLiferay DXPバンドルのosgi/modulesフォルダに取り込まれます。
モジュールの解決プロセスをスキップする
解決プロセス中に、特定のモジュールの検証をスキップするのが最も簡単な方法である場合があります。これを行うには、ワークスペースのルートにあるbuild.gradleファイルを開き、ファイルの下部に以下のGradleコードを挿入します。
targetPlatform {
resolveOnlyIf { project ->
project.name != 'PROJECT_NAME'
}
}
PROJECT_NAMEフィラーは、使用しているモジュールの名前（例: test-api）に置き換えてください。
Target Platformプラグインを完全に無効にする場合は、build.gradleファイルにわずかに異なるディレクティブを追加します。
targetPlatform {
onlyIf { project ->
project.name != 'PROJECT_NAME'
}
}
これにより、resolveタスクの実行がスキップされ、BOMの依存関係の管理が無効になります。
これで、resolveタスクがモジュールプロジェクトをスキップするようになります。
Liferay DXPのカスタマイズされたディストリビューションへの依存
プロジェクトの依存しているJARのリストを手動で指定するだけでは不十分な場合があります。アプリを実行するにあたって、カスタマイズされたLiferay DXPインスタンスが必要な場合は、アップデートされたリストを使用して、ターゲットプラットフォームの機能のデフォルトリストを再作成する必要があります。カスタマイズされたLiferay DXPインスタンスの2つの例を以下で説明します。
例1：外部機能の活用
外部機能/フレームワークには、デフォルトではダウンロード可能なバンドルに含まれていないものの、利用可能なものが多数あります。機能/フレームワークをデプロイすることで、モジュールプロジェクトで利用できるようになります。ただし、アプリを検証する場合は、resolveタスクはデフォルトで含まれていない外部機能にアクセスすることができません。たとえば、このタイプの外部フレームワークにはAudience Targetingがあります。Audience Targetingフレームワークに依存するLiferay Audience Targetingルールを作成している場合、モジュールに多数のJARを提供することは簡単にはできません。この場合、コードが依存するプラットフォームをインストールし、Liferay DXPインスタンスが提供する機能のアップデートされたリストを再作成する必要があります。
例2：カスタマイズされたコア機能の活用
Liferay DXPのコア機能を拡張して、対象ユーザーにカスタマイズされたエクスペリエンスを提供することができます。デプロイしたら、これらのカスタマイズが存在するものと想定して、その上に他のものをビルドすることができます。ただし、カスタマイズに起因する新しい機能は、ターゲットプラットフォームのデフォルトの機能リストでは使用できません。したがって、アプリケーションがデフォルト以外の機能に依存している場合、resolveタスク中に失敗します。これを回避するには、カスタマイズしたLiferay DXPインスタンスが提供する機能の新しいリストを再作成する必要があります。
現在のワークスペースのインスタンスに基づいてターゲットプラットフォームの機能（distro JAR）を再作成するには、以下の手順に従います。
-
ワークスペースに保存されているLiferay DXPインスタンスを起動します。依存予定のプラットフォームがインストールされていることを確認してください。
-
BND Remote Agent JAR ファイルをダウンロードして、
osgi/modulesフォルダにコピーします。 -
ワークスペースのルートフォルダから、以下のコマンドを実行します。
bnd remote distro -o custom_distro.jar release.portal.distro 7.1.0Liferay DXPのユーザーは
release.portal.distroのアーティファクト名をrelease.dxp.distroに置き換え、バージョン7.1.10のシンタックスを使う必要があります。これにより、Liferay DXPで実行されている新しくデプロイされたBNDエージェントに接続し、
custom_distro.jarという名前の新しいdistro JARを作成します。その他の機能はすべてLiferay DXPインスタンスに基づいて機能を継承するため、ワークスペースバンドルが本番環境でリリースする予定のバージョンと一致していることを確認してください。 -
ワークスペースのルート
build.gradleファイルに移動し、以下の依存関係を追加します。dependencies { targetPlatformDistro files('custom_distro.jar') }
これで、ワークスペースは提供されているデフォルトのJARファイルではなく、カスタムのdistro JARファイルを指すようになりました。resolveタスクを実行して、新しい機能セットに対してモジュールを検証します。