AEM プロジェクトの構造

この記事では、AEM as a Cloud Service との互換性を保つために Adobe Experience Manager Maven プロジェクトに必要な変更について説明します。互換性を保つには、プロジェクトが可変コンテンツと不変コンテンツの分離に従っていること、矛盾のない決定論的なデプロイメントの作成に必要な依存関係が設定されていること、デプロイ可能な構造にプロジェクトがパッケージ化されていることが必要です。

AEM アプリケーションのデプロイメントは、単一の AEM パッケージで構成する必要があります。次に、そのパッケージには、コード、設定、補助的なベースラインコンテンツなど、アプリケーションが機能するのに必要なあらゆるもので構成されるサブパッケージが含まれている必要があります。

AEM では、コンテンツ​と​コード​を分離する必要があります。つまり、単一のコンテンツパッケージを​両方/appsおよびランタイム書き込み可能な領域（たとえば、/content、/conf、/home、または /apps 以外の任意のもの）にデプロイすることは​できません。代わりに、アプリケーションを AEM にデプロイするには、コードとコンテンツを別々のパッケージに分離する必要があります。

このドキュメントで概要を説明しているパッケージ構造は、ローカル開発デプロイメントと AEM as a Cloud Service デプロイメントの​両方​に対応しています。

リポジトリの可変領域と不変領域

/apps と /libs は AEM の​不変​領域と見なされます。AEM の起動後（例：実行時）に変更（作成、更新、削除）できないからです。実行時に不変領域を変更しようとすると失敗します。

リポジトリー内のそれ以外の領域（/content、/conf、/var、/etc、/oak:index、/system、/tmp、など）はすべて​可変​領域です。つまり、実行時に変更できます。

Oak インデックス

Oak インデックス（/oak:index）は、AEM as a Cloud Service のデプロイメントプロセスによって特別に管理されます。これは、新しいインデックスがデプロイされて完全に再識別されるまで、Cloud Manager は新しいコードイメージに切り替わる前に待機する必要があるからです。

このため、Oak インデックスは実行時に可変ですが、可変パッケージがインストールされる前にインストールできるように、コードとしてデプロイする必要があります。したがって、/oak:index 設定はコードパッケージの一部であり、以下に説明するコンテンツパッケージの一部ではありません。

推奨されるパッケージ構造

この図は、推奨されるプロジェクト構造とパッケージデプロイメントアーティファクトの概要を示しています。

推奨されるアプリケーションデプロイメント構造は次のとおりです。

コードパッケージ／OSGi バンドル

• OSGi バンドルの Jar ファイルが生成され、すべてのプロジェクトに直接埋め込まれます。

• ui.apps パッケージは、デプロイされるすべてのコードを含んでおり、/apps にのみデプロイされます。ui.apps パッケージの共通要素には次のものがありますが、これらに限定されるわけではありません。

  • コンポーネントの定義と HTL スクリプト
    • /apps/my-app/components
  • JavaScript と CSS（クライアントライブラリ経由）
    • /apps/my-app/clientlibs
  • /libs のオーバーレイ
    • /apps/cq、/apps/dam/ など
  • コンテキスト対応のフォールバック設定
    • /apps/settings
  • ACL（権限）
    • /apps の配下にある任意のパスの任意の rep:policy
  • 事前コンパイル済みバンドルスクリプト

コンテンツパッケージ

• ui.content パッケージには、すべてのコンテンツと設定が含まれています。コンテンツパッケージには、ui.apps パッケージまたは ui.config パッケージに含まれないすべてのノード定義が含まれます。言い換えれば、/apps または /oak:index に含まれないすべてが含まれます。ui.content パッケージの共通要素には次のものがありますが、これらに限定されるわけではありません。
  • コンテキスト対応の設定
    • /conf
  • 必須の、複雑なコンテンツの構造。すなわち、Repo Init で定義されたベースラインコンテンツの構造に基づいて構築され、そこからさらに拡張されるコンテンツの構築。）
    • /content、/content/dam など
  • 管理されるタグ付け分類
    • /content/cq:tags
  • レガシー etc ノード（理想的には、これらのノードを他の非 etc 場所に移行）
    • /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 バンドル JAR
    • site-a.ui.apps：サイト A に必要なコードをデプロイします
    • site-a.ui.config：サイト A に必要な OSGi 設定をデプロイします
    • site-a.ui.content：サイト A に必要なコンテンツと設定をデプロイします
    • site-b.core サイト B に必要な OSGi バンドル JAR
    • site-b.ui.apps：サイト B に必要なコードをデプロイします
    • site-b.ui.config：サイト B に必要な OSGi 設定をデプロイします
    • site-b.ui.content：サイト B に必要なコンテンツと設定をデプロイします

• ui.config パッケージには、すべての OSGi 設定 が含まれています。

  • コードと見なされ、OSGi バンドルに属していますが、通常のコンテンツノードは含まれていません。したがって、コンテナパッケージとしてマークされます
  • 実行モード固有の OSGi 構成定義を含む組織フォルダー
    • /apps/my-app/osgiconfig
  • すべてのターゲット AEM as a Cloud Service デプロイメントターゲットに適用されるデフォルトの OSGi 設定を含む、共通の OSGi 設定フォルダー
    • /apps/my-app/osgiconfig/config
  • すべてのターゲット AEM as a Cloud Service デプロイメントターゲットに適用されるデフォルトの OSGi 設定を含む、実行モード固有の OSGi 設定フォルダー
    • /apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
  • Repo Init OSGi 設定スクリプト
    • AEM アプリケーションの論理的な一部である（可変）コンテンツをデプロイする方法として、Repo Init を使用することをお勧めします。Repo Init OSGi 設定は、上述のように適切な config.<runmode> フォルダーに配置し、次の定義に使用します。
      • ベースラインコンテンツの構造
      • ユーザー
      • サービスユーザー
      • グループ
      • ACL（権限）

追加のアプリケーションパッケージ

独自のコードとコンテンツパッケージで構成される他の AEM プロジェクトを AEM のデプロイメントで使用する場合は、そのコンテナパッケージをプロジェクトの all パッケージに埋め込む必要があります。

例えば、2 つのベンダーの AEM アプリケーションを含む AEM プロジェクトは、次のようになります。

• all コンテンツパッケージに次のパッケージが埋め込まれて、単一のデプロイメントアーティファクトが作成されます。
  • core AEM アプリケーションで必要な OSGi バンドル JAR
  • ui.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 設定スニペット を参照してください。

Adobe Cloud Manager によるデプロイメント用のパッケージのマーク

デフォルトでは、Adobe Cloud Manager は Maven ビルドで生成されたすべてのパッケージを組み込みますが、コンテナ（all）パッケージはすべてのコードパッケージおよびコンテンツパッケージを含んだ単一のデプロイメントアーティファクトなので、必ず、コンテナ（all）パッケージ のみ をデプロイします。これを確実に行うには、Maven ビルドで生成される他のパッケージを、<properties><cloudManagerTarget>none</cloudManageTarget></properties> という FileVault コンテンツパッケージ Maven プラグイン設定でマークする必要があります。

Repo Init

Repo Init は、フォルダーツリーなどの一般的なノード構造から、ユーザー、サービスユーザー、グループ、ACL 定義まで、JCR 構造を定義する手順（スクリプト）を提供します。

Repo Init の主な利点は、スクリプトで定義されたすべてのアクションを実行する暗黙の権限があり、デプロイのライフサイクルの早い段階で呼び出され、必要な JCR 構造がすべて実行されることです。

Repo Init スクリプト自体はスクリプトとして ui.config プロジェクト内に存在しますが、スクリプトは次の可変構造を定義するために使用でき、また使用する必要があります。

• ベースラインコンテンツの構造
• サービスユーザー
• ユーザー
• グループ
• ACL

Repo Init スクリプトは RepositoryInitializer OSGi ファクトリ設定の scripts エントリとして保存されるので、実行モードで暗黙的にターゲット化でき、AEM オーサーと AEM パブリッシュサービス間の Repo Init スクリプトの違いや、環境（開発、ステージ、実行）間の違いを可能にします。

Repo Init OSGi の設定は、複数行をサポートするため .configOSGi 設定形式で書き込むのが最適です。これは、.cfg.jsonOSGi 設定の定義に使用するベストプラクティスの例外です。

ユーザーとグループを定義する場合、グループのみがアプリケーションの一部と見なされ、またここで定義される必要がある機能に不可欠なものと見なされます。組織のユーザーとグループは、実行時に AEM で定義する必要があります。例えば、カスタムワークフローが名前付きのグループに作業を割り当てる場合、そのグループは AEM アプリケーションの Repo Init を介して定義する必要がありますが、グループ化が単なる組織（「Wendy のチーム」や「Sean のチーム」など）の場合、これらは最適な定義で、実行時に AEM で管理されます。

Repo Init スクリプトの全語彙は、Apache Sling Repo Init ドキュメントで入手できます。

リポジトリー構造パッケージ

コードパッケージでは、（あるコードパッケージが別のコードパッケージをオーバーライドしないように）正しい構造的依存関係を確保する <repositoryStructurePackage> を参照するように、FileVault Maven プラグインの設定を指定する必要があります。プロジェクト用に独自のリポジトリー構造パッケージを作成することができます。

これは、コードパッケージ（<packageType>application</packageType> でマークされた任意のパッケージ）にのみ必要​です。

アプリケーション用のリポジトリー構造パッケージの作成方法については、リポジトリー構造パッケージの作成を参照してください。

なお、コンテンツパッケージ（<packageType>content</packageType>）には、このリポジトリー構造パッケージは必要​ありません。

コンテナパッケージへのサブパッケージの埋め込み

コンテンツパッケージまたはコードパッケージは、特別な「サイドカー」フォルダーに格納され、FileVault Maven プラグインの <embeddeds> 設定を使用して、AEM オーサーと AEM パブリッシュのどちらか一方または両方へのインストールの対象とすることができます。<subPackages> 設定は使用しないでください。

一般的な使用例は次のとおりです。

• AEM オーサーユーザーと AEM パブリッシュユーザーで異なる ACL／権限
• AEM オーサーでのみアクティビティをサポートするために使用される設定
• AEM オーサーでのみ実行する必要があるコード（バックオフィスシステムとの統合など）

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 パブリッシュにのみコンテンツと設定がデプロイされます

コンテナパッケージのフィルター定義

コンテナパッケージにコードおよびコンテンツ用のサブパッケージが埋め込まれるので、埋め込まれるターゲットのパスをコンテナプロジェクトの filter.xml に追加して、埋め込まれたパッケージがビルド時にコンテナパッケージに確実に組み込まれるようにする必要があります。

デプロイするサブパッケージを格納した第 2 レベルのフォルダーに対応する <filter root="/apps/<my-app>-packages"/> エントリを追加するだけです。

サードパーティパッケージの埋め込み

すべてのパッケージは、アドビが公開している Maven アーティファクトリポジトリーまたは公開されている参照可能なサードパーティ Maven アーティファクトリポジトリーを通じて入手できる必要があります。

アドビが公開している Maven アーティファクトリポジトリー​にサードパーティパッケージがある場合、Adobe Cloud Manager でアーティファクトを解決するための設定は、それ以上必要ありません。

公開されているサードパーティ Maven アーティファクトリポジトリー​にサードパーティパッケージがある場合は、このリポジトリーをプロジェクトの pom.xml に登録し、上記の方法に従って埋め込む必要があります。

サードパーティのアプリケーション／コネクタは、その all パッケージをプロジェクトのコンテナ（all）パッケージのコンテナとして使用して埋め込む必要があります。

Maven の依存関係を追加する場合は、Maven の標準的な手法に従います。サードパーティアーティファクト（コードパッケージとコンテンツパッケージ）の埋め込みについては、上記のとおりです。

ui.apps パッケージと ui.content パッケージの依存関係

パッケージの適切なインストールを確実に行うために、パッケージ間の依存関係を設定することをお勧めします。

一般的なルールとしては、可変コンテンツを格納したパッケージ（ui.content）は、可変コンテンツのレンダリングと使用をサポートする不変コード（ui.apps）に依存します。

この一般的なルールの例外として重要なのは、不変コードパッケージ（ui.apps など）に OSGi バンドル​のみ​含まれている場合です。この場合、AEM パッケージでは不変コードパッケージへの依存関係を宣言する必要はありません。その理由は、OSGi バンドル のみ を含んだ不変コードパッケージは AEM パッケージマネージャー には登録されていないので、そのコードパッケージに依存するあらゆる AEM パッケージは依存関係の設定が十分でなく、インストールに失敗するからです。

コンテンツパッケージの依存関係の一般的なパターンは以下のとおりです。

デプロイメントパッケージ間のシンプルな依存関係

シンプルな依存関係は、可変コンテンツパッケージ 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 インスタンスに​完全に対応​しています。

POM XML スニペット

上記の推奨事項に合わせて 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>
    ...

Adobe Cloud Manager によるデプロイメント用のパッケージのマーク

コンテナ（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 スクリプトを含む 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 リポジトリーで必要なものがあれば、それらのリポジトリーディレクティブをリアクタープロジェクトの 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>

その他のリソース

• Maven を使用したパッケージの管理
• FileVault コンテンツパッケージ Maven プラグイン

Business.Adobe.com リソース