ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

パッケージのインポート

他のモジュールで提供されている機能が必要になることはよくあります。この機能にアクセスするには、他のモジュールから自分のモジュールのクラスパスにパッケージをインポートする必要があります。このためには、これらの他のモジュールが、必要な機能を含むパッケージをすでにエクスポートしている必要があります。 OSGiフレームワークは、パッケージをインポートするモジュールのクラスパスに接続します。モジュールJARのMETA-INF/MANIFEST.MFファイルは、Import-Package OSGiヘッダを使用してパッケージをインポートします。

Import-Package: javax.portlet,com.liferay.portal.kernel.util

便利なことに、ワークスペースベースのモジュールプロジェクトは、必要なパッケージを自動的に検出し、それらをモジュールマニフェストのパッケージインポートリストに追加します。場合によっては手動で指定する必要があります。

2つの異なるパッケージインポートのシナリオがあります。

パッケージの自動インポート
手動パッケージインポート

これらのシナリオでパッケージのインポートがどのように指定されるかについては、以下をお読みください。

パッケージの自動インポート

チュートリアルの例からの Workspaceベースのプロジェクト（モジュールプロジェクトを参照）、または Blade CLI または Liferay Developer Studio を使用して作成されたプロジェクトでは、 Bndを使用します。 Gradle プラグインは Bndを呼び出し、Gradle の依存関係を読み取ってインポートを解決します。プロジェクトの JAR をビルドすると、 Bnd はモジュールが使用するパッケージを検出し、 META-INF/MANIFEST.MF ファイルを生成し、パッケージを Import-Package ヘッダーに割り当てます。その意味で、パッケージのインポートは自動的に行われます。なぜなら、依存関係を定義する必要があるのは、1か所（ビルドスクリプト）だけだからです。

注

Liferayのプロジェクトテンプレートは、サードパーティのGradleプラグインを使用して Bndを呼び出します。

たとえば、Gogoコマンドサンプルのbuild.gradleは、com.liferay.portal.kernelおよびorg.osgi.service.component.annotationsのパッケージを使用します。サンプルのbuild.gradleファイルは次のとおりです。

dependencies {
    compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel"
    compileOnly group: "org.osgi", name: "org.osgi.service.component.annotations"
}

BndがサンプルJARのMETA-INF/MANIFEST.MFファイルで生成するImport-Packageヘッダは次のとおりです。

Import-Package: com.liferay.portal.kernel.service;version="[4.3,5)"

ビルドファイルは依存関係を指定します。 Bnd はモジュールのクラスパスを調べて、モジュールが使用するパッケージをインポートします。検査には、クラスパス—で見つかったすべてのクラスが含まれます。これには、埋め込まれたサードパーティライブラリ JARのクラスも含まれます。

注

プラグイン WAR プロジェクトの場合、Liferay の WAB ジェネレーターは、WAR の JSP、記述子ファイル、およびクラス（ WEB-INF/classes および埋め込み JAR 内）で使用されるパッケージを検出します。また、WAB ジェネレーターは、 web.xml、 liferay-web.xml、 portlet.xml、 liferay-portlet.xml、および liferay-hook.xml 記述子ファイルを検索します。プラグインの WEB-INF/classes フォルダにも、埋め込まれた JAR にも見つからないクラスのパッケージインポートを追加します。

手動パッケージインポート

モジュールが次の場所でのみクラスを参照する場合は、パッケージインポートを手動で追加する必要があります。

認識されない記述子ファイル
カスタムまたは認識されない記述子要素または属性
リフレクションコード
クラスローダーコード

パッケージを手動でインポートする方法は次のとおりです。

モジュールのbnd.bndファイルを開きます。
Import-Packageヘッダを追加します。
パッケージをヘッダのパッケージリストに追加します。

Import-Package: [... existing package list,][add the package here]

注

プラグイン WAR プロジェクトにパッケージを手動でインポートするには、上記のような Import-Package ヘッダーをプロジェクトの WEB-INF/liferay-plugin-package.properties ファイルに追加します。

Java APIパッケージ

Java ポートレットなどの Java API のパッケージは、意味的にバージョン管理されていませんが、ポータブル Java コントラクトを備えています。各APIのコントラクトは、それが満たすJSRを指定します。これらのAPIを使用するモジュールは、APIコントラクトの要件を指定する必要があります。コントラクト要件は、インポートされたAPIパッケージとのモジュールの関係を定義します。実行しているシステムが正確なコントラクトを提供しない場合、モジュールは解決されません。欠落しているパッケージを解決するほうが、実行中の非互換性の失敗を処理するよりもましです。

ワークスペースベースのプロジェクトは、Portable Java Contracts を自動的に指定します。たとえば、モジュールがJavaポートレットAPIを使用し、Javaポートレット2.0アーティファクトに対してコンパイルする場合、パッケージのコントラクト要件がモジュールのマニフェストに追加されます。

注

WAR プロジェクトは Bnd を使用せず、 WEB-INF/liferay-plugin-package.properties ファイルで契約を指定する必要があります。たとえば、 JavaPortlet 2.0 に指定されたコントラクトは次のとおりです: Import-Package: javax.portlet Require-Capability: osgi.contract;filter:=(&(osgi.contract=JavaPortlet)(version=2.0))

　これで、モジュールで使用するすべての種類のパッケージをインポートできるようになりました。

Capability: