1. Liferay Help Center
  2. Liferay DXP 7.1開発者用チュートリアル
  3. Liferay Portal 6から7へ

ドキュメンテーション

プラグインの依存関係の解決

プラグインプロジェクトをLiferay Dev Studio DXPにインポートしたので、おそらく使用するLiferayクラスの一部のコンパイルエラーが表示されます。 これらのクラスは、移動、名前変更、または削除されているため、未定義のクラスまたは未解決のシンボルとしてリストされます。 Liferay DXPのモジュール化の一環として、これらのクラスの多くは新しいモジュールに存在します。

プラグインのこれらすべてのLiferayクラスを解決する必要があります。 クラスの変更の一部は、迅速かつ簡単に修正できます。 新しいモジュールに関連する変更は、解決するためにより多くの努力を必要としますが、それでも実行するのは簡単です。

Liferayクラスの変更と必要な適応について、ここで説明します。

  1. クラスをクラスパスにあるパッケージに移動：一般的で簡単に修正できる変更です。 モジュールはすでにクラスパスにあるため、クラスのインポートをアップデートするだけで済みます。 これを行うには、Liferayコードアップグレードツールを使用するか、Dev Studio DXPでインポートを整理します。 Upgrade Plannerは移動した各クラスを報告して、1つずつ対処します。 インポートをDev Studio DXPで整理すると、複数のクラスが一度で自動的に解決されます。

    通常、前述のEclipse機能を使用して、移動したクラスを解決する方が高速です。 Liferay Dev Studio DXPはEclipseに基づいているため、インポートを整理するキーボード列Ctrl-Shift-oで、クラスパスにクラスのインポートを生成できます。 エラーとしてマークされたインポートはコメント化または削除してから、Ctrl-Shift-oを押してください。 インポートに一致するものが1つしかない場合、Dev Studio DXPはそのインポートステートメントを自動的に生成します。 それ以外の場合は、正しいインポートを選択できるウィザードが表示されます。

  2. クラスパスではなくモジュールに移動したクラス：プロジェクトの依存関係として新しいモジュールを解決する必要があります。 これを行うにはモジュールを識別し、プロジェクトの依存関係を指定する必要があります。

  3. 置換または削除されたクラス：クラスは別のクラスに置き換えられたか、製品から削除されています。 The Upgrade Planner（後述）は、クラスに起きたこと、変更を処理する方法、および変更が行われた理由を説明します。

クラスパス内で移動したクラスの解決は簡単です。 まずはそのようなクラスを先に解決することを検討してください。 このチュートリアルの残りの部分では、最後の2つのケースを解決する方法について説明しますが、まずは必要なモジュールを宣言するためのプラグインプロジェクトの設定から始めます。

モジュールの依存関係の特定

Liferay DXP 7.1以前は、すべてのプラットフォームAPIはportal-service.jarにありました。 これらのAPIの多くは現在、独立したモジュールにあります。 モジュール化はBenefits of Liferay DXP 7.1 for Liferay Portal 6 Developersで説明しているように、多くのメリットをもたらしました 。 その利点の1つは、これらのAPIモジュールがプラットフォームカーネルとは別に進化できるということです。 さらに、今後のアップグレードも簡素化します。 たとえば、LiferayのAPIをすべてチェックする代わりに、各モジュールのSemantic Versioningは、モジュールに後方互換性のない変更が含まれているかどうかを示します。 そのようなモジュール（ある場合）にコードを適合させるだけです。

モジュール化の一環としてportal-service.jar は、ポータルカーネルのAPIを保持し続けるため、適切にportal-kernel.jarへ名前が変更されました。

図1：LiferayはLiferay DXP 7.1向けにポータルサービスJARをリファクタリングしました。 アプリケーションAPIは独自のモジュールに存在するようになり、ポータルサービスJARは*portal-kernel *になりました。

各アプリケーションのモジュールは、アプリケーションのAPI、実装、またはUIの提供など、特定の目的を持つ、非常にまとまりのある一連のクラスで構成されています。 したがってアプリケーションモジュールの方が、はるかに理解しやすくなっています。 次に、プラグインが参照するクラスを保持するモジュールを追跡します。

Classes Moved fromportal-service.jarでは、portal-service.jarからその新しいモジュールに移動した各クラスをマップするテーブルについて説明しています。 テーブルには、各クラスの新しいパッケージとシンボル名（アーティファクトID）が含まれます。 この情報を使用して、これらのモジュールに対するプラグインの依存関係を構成します。

プラグインは、もともとutil-java、util-bridges、util-taglibまたは util-slf4jとして知られている、Liferayのユーティリティモジュールにあるクラスを参照することがあります。

次の表に、各Liferayユーティリティモジュールのシンボル名を示します。

Liferayユーティリティシンボル名（アーティファクトID）
util-bridgescom.liferay.util.bridges
util-javacom.liferay.util.java
util-slf4jcom.liferay.util.slf4j
util-taglibcom.liferay.util.taglib

Liferay DXPのアプリケーションマネージャ、Felix Gogo Shel、または moduleJARファイルマニフェストを使用して、Liferay DXPインスタンスにデプロイされたモジュールのバージョンを見つけることができます。

依存関係の解決

モジュールのアーティファクトIDとバージョンができたので、プラグインプロジェクトでモジュールを利用可能にできます。 プラグインが使用するモジュールは、コンパイル時および実行時に利用可能でなければなりません。 従来のプラグインプロジェクトでモジュールの依存関係を解決するための、2つのオプションを次に示します。

オプション1：依存関係管理ツールを使用する

オプション2：依存関係をマニュアルで管理する

次のセクションでは、これらのオプションについて説明し、実証します。

依存関係管理ツールを使用する

Ant/Ivy、Mavenおよび Gradleなどの依存関係管理ツールでは、お使いのプラグインが必要なパッケージを提供するJavaアーティファクトの取得を促進します。 パブリックリポジトリまたはプロキシとして設定した内部リポジトリから、アーティファクトをダウンロードできます。 内部リポジトリから、依存関係を監査できます。

LiferayプラグインSDKは、Ant/Ivyインフラストラクチャを提供します。 プラグインプロジェクトのルートフォルダにあるivy.xmlファイルで依存関係を宣言します。 プラグインSDKのAntタスクは、ivy.xmlファイルとプラグインSDKのIvyスクリプトを活用して、指定されたモジュールとその依存関係をダウンロードし、プラグインで利用可能にします。

Liferay Journal APIモジュール、バージョン2.0.1の依存要素の例を次に示します。

<dependency name="com.liferay.journal.api" org="com.liferay" rev="2.0.1" />

各依存関係には、モジュールの名前（name）、組織（org）、およびリビジョン番号（rev）が含まれます。 チュートリアルConfigure Dependenciesでは、モジュールの組織（org）の設定方法について説明しています。

コンパイル時に、Ivyは依存関係JARファイルをキャッシュフォルダにダウンロードして、それらに対してコンパイルできるようにします。

デプロイ時に、Liferay DXPのWAB Generatorは、プラグイン用のOSGi Webアプリケーションバンドル（WAB）を作成します。 WABジェネレーターは、プラグインが使用するJavaパッケージを検出し、それらの依存関係を宣言します。 プラグインは、登録済みのOSGiサービスが提供するパッケージを使用できます。

プロジェクトにivy.xmlファイルがまだない場合は、Liferay Dev Studio DXPで新しいプラグインプロジェクトを作成し、生成されたivy.xmlファイルをコピーすることで取得できます。

Liferay Portal 6.2 ナレッジベースポートレットから、ivy.xmlファイルの例を次に示します。

<?xml version="1.0"?>

<ivy-module
    version="2.0"
    xmlns:m2="http://ant.apache.org/ivy/maven"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd"
>
    <info module="knowledge-base-portlet" organisation="com.liferay">
        <extends extendType="configurations,description,info" location="${sdk.dir}/ivy.xml" module="com.liferay.sdk" organisation="com.liferay" revision="latest.integration" />
    </info>

    <dependencies defaultconf="default">
        <dependency org="com.liferay" name="com.liferay.markdown.converter" rev="1.0.2" />
    </dependencies>
</ivy-module>

プラグインSDKは、プロジェクトIvyファイルと連携して、アーティファクトを保存し、プラグインプロジェクトにアクセスできるようにします。

Ivyやその他の依存関係管理フレームワークを使用したくない場合は、プラグインプロジェクト内にマニュアルで依存関係JARを保存できます。 このことについて次で学びます。

プラグインの依存関係をマニュアルで管理する

プラグインは、コンパイル時および実行時の依存関係の可用性に依存しています。 プラグインをコンパイルするには、プラグインのWEB-INF/libフォルダで依存関係が利用可能であることを確認する必要があります。 プラグインを実行するには、コンテナが以下2つのいずれかを見つけられる状態である必要があります。1つは依存性JavaパッケージがLiferay DXPのOSGiフレームワークで既にアクティブであること、もう1つは依存性JARがプラグイン用に生成されたWABに含まれていることです。 プラグインは、現在所有しているJARとLiferay DXPがエクスポートするパッケージの両方を使用できます。

パッケージポータルエクスポートの使用

Liferay Portal 6向けのプラグインSDKは、JARに対してコンパイルする方法を提供しました。 これらのJARは、liferay-plugin-package.propertiesファイルのportal-dependency-jarsプロパティで指定します。 プラグインのportal-dependency-jarsリストを見ると、LiferayプラグインSDKはJARをプラグインのWEB-INF / libへコピーしています。 プラグインSDKは、プラグインWARにJARを追加していません。 これにより、デプロイを高速化するためにWARが小さくなりました。 WARをリモートで、またはクラスターノードにデプロイする場合に、特にこれが役立ちました。

Liferay DXP 7.1では、portal-dependency-jarsプロパティは廃止され、以前のバージョンとは異なる動作をします。 JavaパッケージのインポートとエクスポートがJARの大規模な使用に取って代わったため、モジュールとWABはJARに関係なくパッケージをインポートできます。 つまり、Liferay DXPは過去に行ったのと同じJavaクラスを、プラグインで利用可能にできないということになります。

これらのファイルには、ポータルがエクスポートするパッケージがリストされています。

  • GitHubリポジトリにあるmodules/core/portal-bootstrap/system.packages.extra.bndファイル。 エクスポートされたパッケージを別々の行にリストしていて、読みやすくなっています。
  • [LIFERAY_HOME]/osgi/core/com.liferay.portal.bootstrap.jarにあるMETA-INF/system.packages.extra.mfファイル。 このファイルは、Liferay DXPバンドルで利用可能です。 エクスポートされたパッケージを、70カラムでラップされた段落にリストします。ここではsystem.packages.extra.bndファイルよりも読みづらくなっています。

まだportal-dependency-jarsプロパティを使用している場合、以下のシナリオのいずれかに遭遇する可能性があります。 事象を解決するには、以下のシナリオの指示に従ってください。

  1. JARを指定しましたが、Liferay DXP 7.1では自分のプラグインで利用できるクラスがありません。

    Liferay Portal 6.2で使用されていたいくつかのJARは、Liferay DXP 7.1で削除されました。 portal-dependency-jarsで指定した場合、Liferay DXPはそれらを提供できません。 それでもなお必要な場合、portal-dependency-jarsプロパティからそれらを削除し、プラグインのWEB-INF/libフォルダに必要なJARを追加します。

  2. JARを指定しました。Liferay DXP 7.1はプラグインがインポートする、すべてのJARパッケージもエクスポートします。

    JARをportal-dependency-jarsリストに保持してください。 プラグインSDKは、コンパイル時にJARをプラグインのWEB-INF/libフォルダにコピーしますが、プラグインWABにJARを追加しません。 プラグイン用に生成されたWABは、実行時に登録済みプロバイダーからパッケージをインポートします。

  3. Liferay DXP 7.1はJARを提供しますが、プラグインがインポートするパッケージをエクスポートしません。

    JARをportal-dependency-jarsプロパティに保持してください。 プラグインSDKは、コンパイル時にJARをプラグインのWEB-INF/libフォルダにコピーし、デプロイ時にJARをプラグインWABに追加します。

除外されたJARについて

ポータルプロパティmodule.framework.web.generator.excluded.pathsは、すべてのLiferay DXP生成WABから削除されるJARを宣言します。 これらのJARはLiferay DXPによって既に提供されているため、WABから除外されます。 プラグインがportal-dependency-jarsプロパティにJARをリストした場合でも、このプロパティに対してリストされたすべてのJARはWABから除外されます。

プラグインがLiferay DXPがエクスポートする異なるバージョンのパッケージを必要とする場合は、module.framework.web.generator.excluded.pathsが除外するものとは異なる名前のJARにそれらを含める必要があります。

たとえば、Liferay DXPのsystem.packages.extra.bnd ファイルは、Spring Frameworkバージョン4.1.9パッケージをエクスポートします。

Export-Package:\
    ...
    org.springframework.*;version='4.1.9',\
    ...

Liferay DXPは、module.framework.web.generator.excluded.pathsポータルプロパティを使用して、JARを除外します。

module.framework.web.generator.excluded.paths=\
    ...
    WEB-INF/lib/spring-aop.jar,\
    WEB-INF/lib/spring-aspects.jar,\
    WEB-INF/lib/spring-beans.jar,\
    WEB-INF/lib/spring-context.jar,\
    WEB-INF/lib/spring-context-support.jar,\
    WEB-INF/lib/spring-core.jar,\
    WEB-INF/lib/spring-expression.jar,\
    WEB-INF/lib/spring-jdbc.jar,\
    WEB-INF/lib/spring-jms.jar,\
    WEB-INF/lib/spring-orm.jar,\
    WEB-INF/lib/spring-oxm.jar,\
    WEB-INF/lib/spring-tx.jar,\
    WEB-INF/lib/spring-web.jar,\
    WEB-INF/lib/spring-webmvc.jar,\
    WEB-INF/lib/spring-webmvc-portlet.jar,\
    ...

WABで異なるSpring Frameworkバージョンを使用するには、対応するSpring Framework JARに、glob-patterned JARsmodule.framework.web.generator.excluded.pathsリストとは異なる名前を付ける必要があります。

たとえば、Spring Frameworkバージョン3.0.7のSpring AOP JARを使用するには、プラグインのWEB-INF/libにそれを含める必要がありますが、spring-aop.jar以外の名前を付けなければなりません。 JAR名にバージョンを追加すると（つまりspring-aop-3.0.7.RELEASE.jar）、除外されたJARと区別され、WABから削除されなくなります。

パッケージポータルを使用してもエクスポートされない

プラグインのWEB-INF/libフォルダにJARをダウンロードしてインストールする必要があります。このJARは、プラグインが要求するものをLiferay DXPがエクスポートしないパッケージを提供します。

これを行うには、次の手順を実行します。

  1. https://search.maven.org/でMaven Centralにアクセスします。

  2. アーティファクトIDおよびグループIDでモジュールを検索します。

  3. 検索結果をナビゲートして、目的のモジュールのバージョンを見つけます。

  4. jarリンクをクリックして、モジュールのJARファイルをダウンロードします。

  5. JARをプロジェクトのWEB-INF/libフォルダに追加します。

図2：Maven Centralを検索した後、* jar *リンクをクリックしてアーティファクトのJARファイルをダウンロードします。

モジュールJARを管理するとき、OSGiフレームワークJARまたはLiferayモジュールJAR（例: com.liferay.journal.api.jar）をデプロイしない**ようにしてください。 これらをデプロイすると、OSGiフレームワークにすでにインストールされているJARと競合します。 2つの異なるクラスローダーにある同一のJARによって、クラスキャストの例外が発生する場合があります。 プラグインのデプロイからそのようなJARを除外する最も簡単な方法は、プラグインのliferay-plugin-package.propertiesにあるdeploy-excludesプロパティに、それらをリストすることです。 それ以外の場合は、プラグインWARファイルからJARをマニュアルで削除する必要があります。 プラグインのliferay-plugin-package.propertiesファイルでJARを除外するには、以下のようなエントリを追加し、角括弧で囲まれた項目を除外するJARファイルの名前に置き換えます。

deploy-excludes=\
    **/WEB-INF/lib/[module-artifact.jar],\
    **/WEB-INF/lib/[another-module-artifact.jar]

例として、OSGiフレームワークJARosgi.core.jarおよびLiferayアプリケーションモジュールJARcom.liferay.journal.api.jarを除外するサンプルのプロパティを次に示します。

deploy-excludes=\
    **/WEB-INF/lib/com.liferay.portal.journal.api.jar,\
    **/WEB-INF/lib/org.osgi.core.jar

次に、どのモジュールがすでにLiferay DXPにインストールされているかを知る方法について示します。 もしLiferay DXPインスタンスに特定のLiferayアプリ・スイートがインストールされている場合、そのアプリ・スイートにあることがわかっているモジュールJARをデプロイしないでください。 たとえば、Web Experience Managementアプリ・スイートがすでにインストールされている場合（Liferay DXPバンドルの場合）、com.liferay.journal.api.jarなどのWebコンテンツモジュールJARをデプロイしないでください。 Liferay DXPのアプリケーションマネージャでモジュールを検索することは、既存のモジュールのインストールを確認する確実な方法です。

« アップグレードの問題の修正重大な変更の解決 »
この記事は役に立ちましたか？
1人中0人がこの記事が役に立ったと言っています