AEM プロジェクトアーキタイプの基本的な使用法と、FileVault コンテンツパッケージ Maven プラグインについて説明します。この記事では、これらの概念の理解を前提としています。
この記事では、AEM as a Cloud Service との互換性を保つために Adobe Experience Manager Maven プロジェクトに必要な変更について説明します。互換性を保つには、プロジェクトが可変コンテンツと不変コンテンツの分離に従っていること、矛盾のない決定論的なデプロイメントの作成に必要な依存関係が設定されていること、デプロイ可能な構造にプロジェクトがパッケージ化されていることが必要です。
AEM アプリケーションのデプロイメントは、単一の AEM パッケージで構成する必要があります。次に、そのパッケージには、コード、設定、補助的なベースラインコンテンツなど、アプリケーションが機能するのに必要なあらゆるもので構成されるサブパッケージが含まれている必要があります。
AEM では、コンテンツとコードを分離する必要があります。つまり、単一のコンテンツパッケージを両方/apps
およびランタイム書き込み可能な領域(たとえば、/content
、/conf
、/home
、または /apps
以外の任意のもの)にデプロイすることはできません。代わりに、アプリケーションを AEM にデプロイするには、コードとコンテンツを別々のパッケージに分離する必要があります。
このドキュメントで概要を説明しているパッケージ構造は、ローカル開発デプロイメントと AEM as a Cloud Service デプロイメントの両方に対応しています。
このドキュメントで概要を説明している設定は、AEM プロジェクト Maven アーキタイプ 24 以降で提供されます。
/apps
と /libs
は AEM の不変領域と見なされます。AEM の起動後(例:実行時)に変更(作成、更新、削除)できないからです。実行時に不変領域を変更しようとすると失敗します。
リポジトリー内のそれ以外の領域(/content
、/conf
、/var
、/etc
、/oak:index
、/system
、/tmp
、など)はすべて可変領域です。つまり、実行時に変更できます。
以前のバージョンの AEM と同様に、/libs
は変更しないでください。/libs
にデプロイできるのは、AEM 製品コードだけです。
Oak インデックス(/oak:index
)は、AEM as a Cloud Service のデプロイメントプロセスによって特別に管理されます。これは、新しいインデックスがデプロイされて完全に再識別されるまで、Cloud Manager は新しいコードイメージに切り替わる前に待機する必要があるからです。
このため、Oak インデックスは実行時に可変ですが、可変パッケージがインストールされる前にインストールできるように、コードとしてデプロイする必要があります。したがって、/oak:index
設定はコードパッケージの一部であり、以下に説明するコンテンツパッケージの一部ではありません。
AEM as a Cloud Service のインデックス作成について詳しくは、 コンテンツの検索とインデックス作成 ドキュメントを参照してください。
この図は、推奨されるプロジェクト構造とパッケージデプロイメントアーティファクトの概要を示しています。
推奨されるアプリケーションデプロイメント構造は次のとおりです。
OSGi バンドルの Jar ファイルが生成され、すべてのプロジェクトに直接埋め込まれます。
ui.apps
パッケージは、デプロイされるすべてのコードを含んでおり、/apps
にのみデプロイされます。ui.apps
パッケージの共通要素には次のものがありますが、これらに限定されるわけではありません。
/apps/my-app/components
/apps/my-app/clientlibs
/libs
のオーバーレイ
/apps/cq
、/apps/dam/
など/apps/settings
/apps
の配下にある任意のパスの任意の rep:policy
同じコードをすべての環境にデプロイする必要があります。これは、ステージング環境と同じレベルの信頼性検証が実稼動環境でも確実に行われるようにするために必要です。詳しくは、「実行モード」の節を参照してください。
ui.content
パッケージには、すべてのコンテンツと設定が含まれています。コンテンツパッケージには、ui.apps
パッケージまたは ui.config
パッケージに含まれないすべてのノード定義が含まれます。言い換えれば、/apps
または /oak:index
に含まれないすべてが含まれます。ui.content
パッケージの共通要素には次のものがありますが、これらに限定されるわけではありません。
/conf
/content
、/content/dam
など/content/cq:tags
/etc
all
パッケージはコンテナパッケージで、デプロイ可能なアーティファクト、OSGI バンドル JAR ファイル、 埋め込みとしての ui.apps
、ui.config
、ui.content
パッケージのみが含まれます。all
パッケージにはそれ自体のコンテンツやコードを含めることはできず、リポジトリーへのあらゆるデプロイメントをサブパッケージまたは OSGi バンドル JAR ファイルに委任します。
<subPackages>
設定ではなく、FileVault パッケージ Maven プラグインの埋め込み設定を使用して、パッケージが組み込まれるようになりました。
Adobe Experience Manager の複雑なデプロイメントの場合は、AEM 内の具体的なサイトまたはテナントを表す複数の ui.apps
、ui.config
および ui.content
プロジェクト/パッケージを作成するほうが望ましいことがあります。その場合は、必ず、可変コンテンツと不変コンテンツの分割に従い、必要なコンテンツパッケージおよび OSGi バンドル JAR ファイルを all
コンテナコンテンツパッケージにサブパッケージとして埋め込みます。
複雑なデプロイメントコンテンツパッケージ構造は、例えば、次のようになります。
all
コンテンツパッケージに次のパッケージが埋め込まれて、単一のデプロイメントアーティファクトが作成されます。
common.ui.apps
:サイト A とサイト B の両方に必要なコードをデプロイしますsite-a.core
サイト A に必要な OSGi バンドル JARsite-a.ui.apps
:サイト A に必要なコードをデプロイしますsite-a.ui.config
:サイト A に必要な OSGi 設定をデプロイしますsite-a.ui.content
:サイト A に必要なコンテンツと設定をデプロイしますsite-b.core
サイト B に必要な OSGi バンドル JARsite-b.ui.apps
:サイト B に必要なコードをデプロイしますsite-b.ui.config
:サイト B に必要な OSGi 設定をデプロイしますsite-b.ui.content
:サイト B に必要なコンテンツと設定をデプロイしますui.config
パッケージには、すべての OSGi 設定 が含まれています。
/apps/my-app/osgiconfig
/apps/my-app/osgiconfig/config
/apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
config.<runmode>
フォルダーに配置し、次の定義に使用します。
独自のコードとコンテンツパッケージで構成される他の AEM プロジェクトを AEM のデプロイメントで使用する場合は、そのコンテナパッケージをプロジェクトの all
パッケージに埋め込む必要があります。
例えば、2 つのベンダーの AEM アプリケーションを含む AEM プロジェクトは、次のようになります。
all
コンテンツパッケージに次のパッケージが埋め込まれて、単一のデプロイメントアーティファクトが作成されます。
core
AEM アプリケーションで必要な OSGi バンドル JARui.apps
:AEM アプリケーションで必要なコードをデプロイしますui.config
:AEM アプリケーションで必要な OSGi 設定をデプロイしますui.content
:AEM アプリケーションで必要なコンテンツと設定をデプロイしますvendor-x.all
:ベンダー X アプリケーションで必要なすべて(コードとコンテンツ)をデプロイしますvendor-y.all
:ベンダー Y アプリケーションで必要なすべて(コードとコンテンツ)をデプロイしますパッケージは、宣言済みのパッケージタイプでマークされる必要があります。パッケージタイプは、パッケージの目的とデプロイメントを明確にするのに役立ちます。
packageType
を container
に設定する必要があります。コンテナパッケージには通常のノードを含めることはできません。OSGi バンドル、設定、サブパッケージのみを使用できます。AEM as a Cloud Service のコンテナは、 インストールフック を使用できません。packageType
を application
に設定する必要があります。packageType
を content
に設定する必要があります。詳しくは、Apache Jackrabbit FileVault - Package Maven プラグインのドキュメント、Apache Jackrabbit パッケージタイプ、以下の FileVault Maven 設定スニペット を参照してください。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
デフォルトでは、Adobe Cloud Manager は Maven ビルドで生成されたすべてのパッケージを組み込みますが、コンテナ(all
)パッケージはすべてのコードパッケージおよびコンテンツパッケージを含んだ単一のデプロイメントアーティファクトなので、必ず、コンテナ(all
)パッケージ のみ をデプロイします。これを確実に行うには、Maven ビルドで生成される他のパッケージを、<properties><cloudManagerTarget>none</cloudManageTarget></properties>
という FileVault コンテンツパッケージ Maven プラグイン設定でマークする必要があります。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
Repo Init は、フォルダーツリーなどの一般的なノード構造から、ユーザー、サービスユーザー、グループ、ACL 定義まで、JCR 構造を定義する手順(スクリプト)を提供します。
Repo Init の主な利点は、スクリプトで定義されたすべてのアクションを実行する暗黙の権限があり、デプロイのライフサイクルの早い段階で呼び出され、必要な JCR 構造がすべて実行されることです。
Repo Init スクリプト自体はスクリプトとして ui.config
プロジェクト内に存在しますが、スクリプトは次の可変構造を定義するために使用でき、また使用する必要があります。
Repo Init スクリプトは RepositoryInitializer
OSGi ファクトリ設定の scripts
エントリとして保存されるので、実行モードで暗黙的にターゲット化でき、AEM オーサーと AEM パブリッシュサービス間の Repo Init スクリプトの違いや、環境(開発、ステージ、実行)間の違いを可能にします。
Repo Init OSGi の設定は、複数行をサポートするため .config
OSGi 設定形式で書き込むのが最適です。これは、.cfg.json
OSGi 設定の定義に使用するベストプラクティスの例外です。
ユーザーとグループを定義する場合、グループのみがアプリケーションの一部と見なされ、またここで定義される必要がある機能に不可欠なものと見なされます。組織のユーザーとグループは、実行時に AEM で定義する必要があります。例えば、カスタムワークフローが名前付きのグループに作業を割り当てる場合、そのグループは AEM アプリケーションの Repo Init を介して定義する必要がありますが、グループ化が単なる組織(「Wendy のチーム」や「Sean のチーム」など)の場合、これらは最適な定義で、実行時に AEM で管理されます。
Repo Init スクリプトは、インライン scripts
フィールドで定義する必要があり、references
設定は機能しません。
Repo Init スクリプトの全語彙は、Apache Sling Repo Init ドキュメントで入手できます。
完全なスニペットについては、この後の Repo Init スニペット の節を参照してください。
コードパッケージでは、(あるコードパッケージが別のコードパッケージをオーバーライドしないように)正しい構造的依存関係を確保する <repositoryStructurePackage>
を参照するように、FileVault Maven プラグインの設定を指定する必要があります。プロジェクト用に独自のリポジトリー構造パッケージを作成することができます。
これは、コードパッケージ(<packageType>application</packageType>
でマークされた任意のパッケージ)にのみ必要です。
アプリケーション用のリポジトリー構造パッケージの作成方法については、リポジトリー構造パッケージの作成を参照してください。
なお、コンテンツパッケージ(<packageType>content</packageType>
)には、このリポジトリー構造パッケージは必要ありません。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
コンテンツパッケージまたはコードパッケージは、特別な「サイドカー」フォルダーに格納され、FileVault Maven プラグインの <embeddeds>
設定を使用して、AEM オーサーと AEM パブリッシュのどちらか一方または両方へのインストールの対象とすることができます。<subPackages>
設定は使用しないでください。
一般的な使用例は次のとおりです。
AEM オーサーか AEM パブリッシュまたはその両方をターゲットにするには、パッケージを次の形式で all
コンテナパッケージ内の特別なフォルダー位置に埋め込みます。
/apps/<app-name>-packages/(content|application|container)/install(.author|.publish)?
このフォルダー構造の詳細は次のとおりです。
第 1 レベルのフォルダーは /apps
にする必要があります。
第 2 レベルのフォルダーは、フォルダー名の末尾に -packages
が付いたアプリケーションを表します。多くの場合、すべてのサブパッケージが配下に埋め込まれる第 2 レベルのフォルダーは 1 つだけですが、アプリケーションの論理構造を最も適切に表すために、第 2 レベルのフォルダーをいくつでも作成できます。
/apps/my-app-packages
/apps/my-other-app-packages
/apps/vendor-packages
慣例により、サブパッケージが埋め込まれるフォルダーの名前には、-packages
というサフィックスが付けられます。これにより、デプロイメントコードパッケージとコンテンツパッケージが任意のサブパッケージの対象フォルダー /apps/<app-name>/...
にデプロイされなくなり、破壊的な循環インストール動作を避けることができます。
第 3 レベルのフォルダーは、
application
、content
、container
application
フォルダーにはコードパッケージが格納されます。content
フォルダーにはコンテンツパッケージが格納されます。container
フォルダーには、AEM アプリケーションに含まれる可能性のある追加のアプリケーションパッケージが格納されます。第 4 レベルのフォルダーはサブパッケージを格納するもので、次のいずれかにする必要があります。
install
:AEM オーサーと AEM パブリッシュの両方にインストールする場合install.author
:AEM オーサーにのみインストールする場合install.publish
:AEM パブリッシュにのみインストールする場合。なお、サポートされているターゲットは install.author
と install.publish
のみです。その他の実行モードはサポートされていません。例えば、AEM オーサーおよびパブリッシュに固有のパッケージを含んだデプロイメントは、次のようになります。
all
コンテナパッケージに次のパッケージが埋め込まれて、単一のデプロイメントアーティファクトが作成されます。
ui.apps
が /apps/my-app-packages/application/install
に埋め込まれると、AEM オーサーと AEM パブリッシュの両方にコードがデプロイされますui.apps.author
が /apps/my-app-packages/application/install.author
に埋め込まれると、AEM オーサーにのみコードがデプロイされますui.content
が /apps/my-app-packages/content/install
に埋め込まれると、AEM オーサーと AEM パブリッシュの両方にコンテンツと設定がデプロイされますui.content.publish
が /apps/my-app-packages/content/install.publish
に埋め込まれると、AEM パブリッシュにのみコンテンツと設定がデプロイされます完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
コンテナパッケージにコードおよびコンテンツ用のサブパッケージが埋め込まれるので、埋め込まれるターゲットのパスをコンテナプロジェクトの filter.xml
に追加して、埋め込まれたパッケージがビルド時にコンテナパッケージに確実に組み込まれるようにする必要があります。
デプロイするサブパッケージを格納した第 2 レベルのフォルダーに対応する <filter root="/apps/<my-app>-packages"/>
エントリを追加するだけです。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
すべてのパッケージは、アドビが公開している Maven アーティファクトリポジトリーまたは公開されている参照可能なサードパーティ Maven アーティファクトリポジトリーを通じて入手できる必要があります。
アドビが公開している Maven アーティファクトリポジトリーにサードパーティパッケージがある場合、Adobe Cloud Manager でアーティファクトを解決するための設定は、それ以上必要ありません。
公開されているサードパーティ Maven アーティファクトリポジトリーにサードパーティパッケージがある場合は、このリポジトリーをプロジェクトの pom.xml
に登録し、上記の方法に従って埋め込む必要があります。
サードパーティのアプリケーション/コネクタは、その all
パッケージをプロジェクトのコンテナ(all
)パッケージのコンテナとして使用して埋め込む必要があります。
Maven の依存関係を追加する場合は、Maven の標準的な手法に従います。サードパーティアーティファクト(コードパッケージとコンテンツパッケージ)の埋め込みについては、上記のとおりです。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
ui.apps
パッケージと ui.content
パッケージの依存関係 パッケージの適切なインストールを確実に行うために、パッケージ間の依存関係を設定することをお勧めします。
一般的なルールとしては、可変コンテンツを格納したパッケージ(ui.content
)は、可変コンテンツのレンダリングと使用をサポートする不変コード(ui.apps
)に依存します。
この一般的なルールの例外として重要なのは、不変コードパッケージ(ui.apps
など)に OSGi バンドルのみ含まれている場合です。この場合、AEM パッケージでは不変コードパッケージへの依存関係を宣言する必要はありません。その理由は、OSGi バンドル のみ を含んだ不変コードパッケージは AEM パッケージマネージャー には登録されていないので、そのコードパッケージに依存するあらゆる AEM パッケージは依存関係の設定が十分でなく、インストールに失敗するからです。
完全なスニペットについては、この後の POM XML スニペット の節を参照してください。
コンテンツパッケージの依存関係の一般的なパターンは以下のとおりです。
シンプルな依存関係は、可変コンテンツパッケージ ui.content
が不変コードパッケージ ui.apps
に依存するように設定する場合です。
all
には依存関係がありません
ui.apps
には依存関係がありませんui.content
は ui.apps
に依存しています複雑なデプロイメントは、シンプルなケースをさらに拡張したもので、対応する可変コンテンツパッケージと不変コードパッケージの間に依存関係を設定します。必要に応じて、不変コードパッケージ間にも依存関係を設定できます。
all
には依存関係がありません
common.ui.apps.common
には依存関係がありませんsite-a.ui.apps
は common.ui.apps
に依存していますsite-a.ui.content
は site-a.ui.apps
に依存していますsite-b.ui.apps
は common.ui.apps
に依存していますsite-b.ui.content
は site-b.ui.apps
に依存していますこの記事で概要を説明しているプロジェクト構造および編成は、ローカル開発 AEM インスタンスに完全に対応しています。
上記の推奨事項に合わせて Maven プロジェクトに追加できる Maven pom.xml
設定スニペットを以下に示します。
サブパッケージとしてデプロイされるコードパッケージとコンテンツパッケージでは、パッケージに含まれる内容に応じて、アプリケーションかコンテンツのパッケージタイプを宣言する必要があります。
コンテナ all/pom.xml
プロジェクトでは <packageType>
を宣言しません。
コードパッケージでは、packageType
を application
に設定する必要があります。
ui.apps/pom.xml
では、プラグイン宣言 filevault-package-maven-plugin
のビルド設定ディレクティブ <packageType>application</packageType>
でパッケージタイプを宣言します。
...
<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<group>${project.groupId}</group>
<name>my-app.ui.apps</name>
<packageType>application</packageType>
<accessControlHandling>merge</accessControlHandling>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
</configuration>
</plugin>
...
コンテンツパッケージでは、packageType
を content
に設定する必要があります。
ui.content/pom.xml
では、プラグイン宣言 filevault-package-maven-plugin
のビルド設定ディレクティブ <packageType>content</packageType>
でパッケージタイプを宣言します。
...
<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<group>${project.groupId}</group>
<name>my-app.ui.content</name>
<packageType>content</packageType>
<accessControlHandling>merge</accessControlHandling>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
</configuration>
</plugin>
...
コンテナ(all
)プロジェクトを除き、パッケージを生成するすべてのプロジェクトでは、プラグイン宣言 filevault-package-maven-plugin
の <properties>
設定に <cloudManagerTarget>none</cloudManagerTarget>
を追加して、プロジェクトが Adobe Cloud Manager でデプロイされないようにします。コンテナ(all
)パッケージは、Cloud Manager を通じてデプロイされる単一のパッケージでなければなりません。このパッケージに、必要なすべてのコードパッケージとコンテンツパッケージが埋め込まれます。
...
<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
</configuration>
</plugin>
...
Repo Init スクリプトを含む Repo Init スクリプトは、scripts
プロパティを介して RepositoryInitializer
OSGi ファクトリ設定で定義されます。OSGi 設定内で定義されるこれらのスクリプトは、通常の ../config.<runmode>
フォルダーセマンティクスを使用して、実行モードで簡単にスコープできることに注意してください。
スクリプトは通常複数行の宣言なので、JSON ベースの .cfg.json
形式よりも .config
ファイルで定義するほうが簡単です。
/apps/my-app/config.author/org.apache.sling.jcr.repoinit.RepositoryInitializer-author.config
scripts=["
create service user my-data-reader-service
set ACL on /var/my-data
allow jcr:read for my-data-reader-service
end
create path (sling:Folder) /conf/my-app/settings
"]
scripts
OSGi プロパティには、Apache Sling の Repo Init 言語で定義されたディレクティブが含まれます。
ui.apps/pom.xml
と、コードパッケージ(<packageType>application</packageType>
)を宣言する他の任意の pom.xml
で、次のリポジトリー構造パッケージ設定を FileVault Maven プラグインに追加します。プロジェクト用に独自のリポジトリー構造パッケージを作成することができます。
...
<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<repositoryStructurePackages>
<repositoryStructurePackage>
<groupId>${project.groupId}</groupId>
<artifactId>ui.apps.structure</artifactId>
<version>${project.version}</version>
</repositoryStructurePackage>
</repositoryStructurePackages>
</configuration>
</plugin>
...
all/pom.xml
で、次の <embeddeds>
ディレクティブをプラグイン宣言 filevault-package-maven-plugin
に追加します。なお、<subPackages>
設定は使用しないでください。この設定では、/apps/my-app-packages/<application|content|container>/install(.author|.publish)?
ではなく /etc/packages
内のサブパッケージを組み込むことになるからです。
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<embeddeds>
<!-- Include the application's ui.apps and ui.content packages -->
<!-- Ensure the artifactIds are correct -->
<!-- OSGi Bundle Jar file that deploys to BOTH AEM Author and AEM Publish -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.core</artifactId>
<type>jar</type>
<target>/apps/my-app-packages/application/install</target>
</embedded>
<!-- Code package that deploys to BOTH AEM Author and AEM Publish -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.ui.apps</artifactId>
<type>zip</type>
<target>/apps/my-app-packages/application/install</target>
</embedded>
<!-- OSGi configuration code package that deploys to BOTH AEM Author and AEM Publish -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.ui.config</artifactId>
<type>zip</type>
<target>/apps/my-app-packages/application/install</target>
</embedded>
<!-- Code package that deploys ONLY to AEM Author -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.ui.apps.author</artifactId>
<type>zip</type>
<target>/apps/my-app-packages/application/install.author</target>
</embedded>
<!-- Content package that deploys to BOTH AEM Author and AEM Publish -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.ui.content</artifactId>
<type>zip</type>
<target>/apps/my-app-packages/content/install</target>
</embedded>
<!-- Content package that deploys ONLY to AEM Publish -->
<embedded>
<groupId>${project.groupId}</groupId>
<artifactId>my-app.ui.content.publish-only</artifactId>
<type>zip</type>
<target>/apps/my-app-packages/content/install.publish</target>
</embedded>
<!-- Include any other extra packages -->
<embedded>
<groupId>com.vendor.x</groupId>
<artifactId>vendor.plug-in.all</artifactId>
<type>zip</type>
<target>/apps/vendor-packages/container/install</target>
</embedded>
<embeddeds>
</configuration>
</plugin>
...
all
プロジェクトの filter.xml
(all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml
)に、デプロイするサブパッケージを格納したすべての -packages
フォルダーを 含めます。
<filter root="/apps/my-app-packages"/>
埋め込まれるターゲットで複数の /apps/*-packages
が使用されている場合は、それらをすべてここに列挙する必要があります。
Maven リポジトリーをさらに追加すると、Maven リポジトリーの依存関係がチェックされるので、Maven のビルド時間が延長される場合があります。
公開されているサードパーティ Maven リポジトリーで必要なものがあれば、それらのリポジトリーディレクティブをリアクタープロジェクトの pom.xml
に追加します。完全な <repository>
設定は、サードパーティリポジトリープロバイダから入手できるはずです。
<repositories>
...
<repository>
<id>3rd-party-repository</id>
<name>Public 3rd Party Repository</name>
<url>https://repo.3rdparty.example.com/...</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
...
</repositories>
ui.apps
パッケージと ui.content
パッケージの依存関係 ui.content/pom.xml
で、次の <dependencies>
ディレクティブをプラグイン宣言 filevault-package-maven-plugin
に追加します。
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<dependencies>
<!-- Declare the content package dependency in the ui.content/pom.xml on the ui.apps project -->
<dependency>
<groupId${project.groupId}</groupId>
<artifactId>my-app.ui.apps</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
...
</configuration>
</plugin>
...
Maven ビルドの前にターゲットディレクトリをクリーンアップする maven-clean-plugin
プラグインを all/pom.xml
に追加します。
<plugins>
...
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<executions>
<execution>
<id>auto-clean</id>
<!-- Run at the beginning of the build rather than the default, which is after the build is done -->
<phase>initialize</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>