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 以降で提供されます。
AEM の /apps
領域および /libs
領域は、不変とみなされ、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 プラグインの埋め込み設定を使用して、パッケージが組み込まれるようになりました。
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 を使用してそのグループを定義します。ただし、グループ化が単に組織的なもの(「ウェンディのチーム」や「ショーンのチーム」など)の場合、実行時に 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 Third-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>
...
all/pom.xml
に、Maven のビルドの前にターゲットディレクトリをクリーンアップする maven-clean-plugin
プラグインを追加します。
<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>