現在表示中:

概要

このドキュメントでは、Apache Maven に基づく AEM プロジェクトを設定する方法について説明します。

Apache Maven は、ビルドを自動化し、質の高いプロジェクト情報を提供してソフトウェアプロジェクトを管理するためのオープンソースツールです。これは、AEM プロジェクト用に推奨されるビルド管理ツールです。

Maven に基づく AEM プロジェクトのビルドには以下のメリットがあります。

  • IDE に依存しない開発環境
  • アドビが提供する Maven のアーキタイプおよびアーティファクトの使用
  • Maven ベースの開発の設定用の Apache Sling および Apache Felix ツールセットの使用
  • IDE への読み込みが容易(Eclipse、IntelliJ など)
  • 継続的インテグレーションシステムとの統合が容易

Adobe Experience Manager API の依存関係

UberJar とは

「UberJar」は、アドビが提供する特別な Java Archive(JAR)ファイルの非公式な名称です。この JAR ファイルには、Adobe Experience Manager が明らかにしている公開 Java API がすべて含まれています。限定的な外部ライブラリも含まれています。具体的には、AEM で使用可能な、Apache Sling、Apache Jackrabbit、Apache Lucene、Google Guava および画像処理用の 2 つのライブラリ(Werner Randelshofer の CYMK JPEG ImageIO ライブラリと TwelveMonkeys 画像ライブラリ)の公開 API です。UberJar に含まれているのは API インターフェイスとクラスだけです。つまり、AEM の OSGi バンドルによって書き出されるインターフェイスとクラスだけが含まれています。また、UberJar には、書き出される全パッケージの正しいパッケージ書き出してバージョンを定義する MANIFEST.MF ファイルが含まれているので、UberJar に基づいてビルドされるプロジェクトのパッケージ読み込み範囲は必ず正しくなります。

アドビが UberJar を作成した理由

これまで、開発者は様々な AEM ライブラリに対する個別の依存関係を比較的多数管理し、新しい API が使用されるたびに、個別の依存関係を 1 つ以上プロジェクトに追加する必要がありました。1 つのプロジェクトに UberJar を導入すると、30 個の個別の依存関係がプロジェクトから削除されます。

UberJar の使用方法

Apache Maven をビルドシステムとして使用する場合(大部分の AEM Java プロジェクト)は、1 つまたは 2 つの要素を pom.xml ファイルに追加する必要があります。1 つ目は、実際の依存関係をプロジェクトに追加する dependency 要素です。

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.3.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Sonatype Nexus、Apache Archiva または JFrog Artifactory などの Maven Repository Manager を既に使用している場合は、このリポジトリマネージャーを参照するための適切な設定をプロジェクトに追加し、使用しているリポジトリマネージャーにアドビの Maven リポジトリ(https://repo.adobe.com/nexus/content/groups/public/)を追加します。

注意:

不明化されていない jar ファイルは次のようになります。

リポジトリマネージャーを使用していない場合は、repository 要素を pom.xml ファイルに追加する必要があります。

<repositories>
    <repository>
        <id>adobe-public-releases</id>
        <name>Adobe Public Repository</name>
        <url>https://repo.adobe.com/nexus/content/groups/public/</url>
        <layout>default</layout>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>adobe-public-releases</id>
        <name>Adobe Public Repository</name>
        <url>https://repo.adobe.com/nexus/content/groups/public/</url>
        <layout>default</layout>
    </pluginRepository>
</pluginRepositories>

GitHub のコード

このページのコードは GitHub にあります

注意:

これらのリポジトリを Maven の settings.xml ファイル内で設定することもできます。

他のビルドシステム(Apache Ant、Gradle など)のユーザーは、選択したツールに固有の構文に合わせて、同様の手順を実行する必要があります。

UberJar でできること

UberJar を使用して、AEM API(およびプロジェクトが使用する前述の API)に依存するプロジェクトコードをコンパイルできます。OSGi Service Component Runtime(SCR)および OSGi Metatype 情報も生成できます。いくつかの制限はありますが、単体テストを作成して実行することもできます。

UberJar ではできないこと

UberJar は API のみを含むので、実行できません。したがって、UberJar を使用して Adobe Experience Manager を実行することはできません。AEM を実行するには、スタンドアロンまたは Web Application Archive(WAR)形式の AEM Quickstart が必要です。

単体テストに関する制限について

一般的に、単体テストは 3 つの方法で製品 API とやり取りします。いずれの方法も、UberJar によって少しずつ異なる影響を受けます。

ユースケース 1 - API インターフェイスを呼び出すカスタムコード

これは最も一般的なケースで、AEM API で定義されている Java インターフェイスのメソッドをカスタムコードで実行します。このインターフェイスの実装は、直接提供することも、依存関係挿入パターンを使用して挿入することもできます。 このユースケースは UberJar で処理できます。

前者の例を以下に示します。

public class ClassWhichHasAEMInterfacePassedIn {
    /**
     * Get the first length characters of the page title.
     */
    public String getTrimmedTitle(Page page, int length) {
         String title = page.getTitle();
         return StringUtils.left(title, length);
    }
}

後者の例を以下に示します。

@Component
@Service
public class ComponentWhichHasAEMInterfaceInjected implements TitleTrimmer {
    @Reference
    private PageManagerFactory pageManagerFactory;
  
    /**
     * Get the first length characters of the title of the page containing the provided Resource.
     */
    public String getTrimmedTitle(Resource resource, int length) {
        PageManager pageManager = pageManagerFactory.getPageManager(resource.getResourceResolver());
        Page page = pageManager.getContainingPage(resource);
        if (page == null) {
           return null;
        }
        String title = page.getTitle();
        return StringUtils.left(title, length);
    }
}

これらのメソッドの単体テストをおこなうには、JMockitMockitoJMockEasymock などのモック作成フレームワークを使用して、参照される AEM API のモックオブジェクトを作成します。この例では JMockit を使用していますが、特にこのユースケースでは、フレームワーク間の違いはあまりなく、構文的な相違に留まります。

@RunWith(JMockit.class)
public class ClassWhichHasAEMInterfacePassedInTest {
 
    @Tested
    private ClassWhichHasAEMInterfacePassedIn instance;
 
 
    @Mocked
    private Page page;
 
 
    @Test
    public void test_that_long_string_is_trimmed() {
        new Expectations() {{
            page.getTitle();
            result = "a really really really really really long string";
        }};
        assertEquals("a really", instance.getTrimmedTitle(page, 8));
    }
}
@RunWith(JMockit.class)
public class ComponentWhichHasAEMInterfaceInjectedTest {
 
 
    @Tested
    private ComponentWhichHasAEMInterfaceInjected instance;
 
 
    @Mocked
    private Page page;
 
 
    @Mocked
    private PageManager pageManager;
 
 
    @Injectable
    private PageManagerFactory pageManagerFactory;
 
 
    @Mocked
    private Resource resource;
 
 
    @Mocked
    private ResourceResolver resourceResolver;
 
    @Test
    public void test_that_long_string_is_trimmed() {
        new Expectations() {{
            resource.getResourceResolver();
            result = resourceResolver;
            pageManagerFactory.getPageManager(resourceResolver);
            result = pageManager;
            pageManager.getContainingPage(resource);
            result = page;
            page.getTitle();
            result = "a really really really really really long string";
        }};
        assertEquals("a really", instance.getTrimmedTitle(resource, 8));
    }
}

ユースケース 2 - API 実装クラスを呼び出すカスタムコード

このユースケースでは、AEM API のクラスの静的メソッドまたはインスタンスメソッドを呼び出します。つまり、ユースケース 1 のようにインターフェイスを参照するのではなく、具象クラスを参照します。 

public class ClassWhichUsesAStaticMethodFromAPI {
     
    /**
     * Get a map of asset titles to asset objects.
     *
     * @param resource either an asset resource or a folder containing assets.
     * @return an map of titles to assets. if an asset doesn't have a title, the name is used instead.
     */
    public Map<String, Asset> getAssetTitles(Resource resource) {
        Iterator<Asset> assets = DamUtil.getAssets(resource);
        Map<String, Asset> result = new HashMap<String, Asset>();
        while (assets.hasNext()) {
            Asset asset = assets.next();
            String title = asset.getMetadataValue(DamConstants.DC_TITLE);
            if (title == null) {
                title = asset.getName();
            }
            result.put(title, asset);
        }
        return result;
    }
}
public class ClassWhichUsesAnInstanceMethodFromAPI {
     
    /**
     * Count the number of paragraphs in a parsys.
     *
     * @param resource the parsys resource
     * @return the count
     */
    public int countParagraphs(Resource resource) {
        return new ParagraphSystem(resource).paragraphs().size();
    }
}

このユースケースは UberJar で処理できます。ただし、性能テストについては、可能であればやはり API のモックを作成することをお勧めします。

@RunWith(JMockit.class)
public class ClassWhichUsesAStaticMethodFromAPITest {
 
 
    @Tested
    private ClassWhichUsesAStaticMethodFromAPI instance;
 
 
    @Mocked(stubOutClassInitialization = true)
    private DamUtil unusedDamUtil = null;
 
 
    @Mocked
    private Resource resource;
 
    @Test
    public void test_that_empty_iterator_produces_empty_map() {
        new Expectations() {
            {
                DamUtil.getAssets(resource);
                result = Collections.<Asset> emptySet().iterator();
            }
        };
        Map<String, Asset> result = new ClassWhichUsesAStaticMethodFromAPI().getAssetTitles(resource);
        assertNotNull(result);
        assertEquals(0, result.size());
    }
    @Test
    public void test_with_reference_search() {
        assertTrue(true);
    }
}
@RunWith(JMockit.class)
public class ClassWhichUsesAnInstanceMethodFromAPITest {
 
 
    @Tested
    private ClassWhichUsesAnInstanceMethodFromAPI instance;
 
    @Mocked
    private Resource parsys;
 
 
    @Mocked
    private Paragraph firstPar;
 
 
    @Mocked
    private Paragraph secondPar;
 
 
    @Test
    public void test_empty_parsys_returns_zero() {
        new MockUp<ParagraphSystem>() {
            @Mock
            public void $init(Resource resource) {
                assertEquals(parsys, resource);
            }
            @Mock
            public List<Paragraph> paragraphs() {
                return Collections.<Paragraph> emptyList();
            }
        };
        assertEquals(0, instance.countParagraphs(parsys));
    }
}

ユースケース 3 - API のベースクラスを拡張するカスタムコード

SCR 生成と同様に、カスタムコードで AEM API のベースクラス(抽象または具象)を拡張する場合は、それをテストするために UberJar を使用する必要があります

Maven を使用した一般的な開発タスク

content モジュールにパスを追加する方法

content モジュールには、Maven でビルドされる AEM パッケージ用のフィルターを定義する src/main/content/META-INF/vault/filter.xml ファイルが格納されます。Maven アーキタイプによって作成されるこのファイルは次のようになります。

src/main/content/META-INF/vault/filter.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
</workspaceFilter>

このファイルは様々な方法で使用されます。

  • パッケージにインクルードするコンテンツを決定するために content-package-maven-plugin で使用します。
  • 考慮するパスを決定するために VLT ツールで使用します。
  • AEM パッケージマネージャーでパッケージが再ビルドされる場合は、インクルードするパスもこのファイルで定義されます。

アプリケーションの要件によっては、次のような他のコンテンツをインクルードするためにこれらのパスを追加する必要があります。

  • ロールアウト設定
  • ブループリント
  • ワークフローモデル
  • デザインページ
  • サンプルコンテンツ

パスを追加するには、<filter> 要素を追加します。

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
    <filter root="/etc/msm/rolloutconfigs/myrolloutconfig"/>
    <filter root="/etc/blueprints/mysite/globalsite"/>
    <filter root="/etc/workflow/models/myproject"/>
    <filter root="/etc/designs/myproject"/>
    <filter root="/content/myproject/sample-content"/>
</workspaceFilter>

同期をおこなわずにパスをパッケージに追加する方法

content-package-maven-plugin でビルドされるパッケージに追加する必要があり、ファイルシステムとリポジトリとの間で同期してはならないファイルがある場合は、.vltignore ファイルを使用できます。これらのファイルの構文は .gitignore ファイルと同じです。

例えば、アーキタイプでは、.vltignore ファイルを使用して、バンドルの一部としてインストールする JAR ファイルがファイルシステムに同期されないようにします。

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar

パッケージにパスを追加せずにパスを同期する方法

ファイルシステムとリポジトリとの間で特定のパスの同期を維持し、AEM にインストールするためにビルドするパッケージにはそのパスをインクルードしない場合があります。

典型的な例として、/libs/foundation というパスがあります。開発の目的では、このパスのコンテンツをファイルシステムで使用できるようにします。例えば、IDE では JSP のインクルード(/libs への JSP のインクルード)を解決できます。しかし、ビルドするパッケージにはそのコンテンツをインクルードしません。これは、カスタム実装で変更してはならない製品コードが /libs のコンテンツに含まれているからです。

そのためには、src/main/content/META-INF/vault/filter-vlt.xml ファイルを指定できます。このファイルが存在する場合は、VLT ツールで使用されます。例えば、vlt upvlt ci の実行時、または vlt sync の設定が完了している場合などです。content-package-maven-plugin では、パッケージの作成時に引き続き src/main/content/META-INF/vault/filter.xml ファイルを使用します。

例えば、/libs/foundation を開発用にローカルで使用できるようにして、パッケージに /apps/myproject だけをインクルードする場合は、次の 2 つのファイルを使用します。

src/main/content/META-INF/vault/filter.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/apps/myproject"/>
</workspaceFilter>

src/main/content/META-INF/vault/filter-vlt.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/libs/foundation"/>
    <filter root="/apps/myproject"/>
</workspaceFilter>

また、これらのファイルをパッケージにインクルードしないように maven-resources-plugin を再設定する必要があります。パッケージのインストール時に filter.xml ファイルは適用されません。パッケージマネージャーを使用してパッケージが再びビルドされる場合にのみ適用されます。

それに応じて、コンテンツの POM の <resources> セクションを変更してください。

src/main/content/pom.xml

<!-- ... -->
<resources>
	<resource>
		<directory>src/main/content/jcr_root</directory>
		<filtering>false</filtering>
		<excludes>
			<exclude>**/.vlt</exclude>
			<exclude>**/.vltignore</exclude>
			<exclude>libs/</exclude>
		</excludes>
	</resource>
</resources>
<!-- ... -->

JSP を使用する方法

これまでに説明した Maven 設定では、コンポーネントと対応する JSP もインクルードできるコンテンツパッケージを作成します。ただし、Maven では JSP をコンテンツパッケージに含まれるその他のファイルとして扱い、JSP として認識しません。

AEM でのコンポーネントの動作はまったく同じですが、Maven に JSP を認識させる処理には 2 つの主なメリットがあります。

  • JSP にエラーが含まれている場合に Maven を失敗させることができるので、JSP が最初に AEM にコンパイルされるときではなく、ビルド時にエラーを特定できます。
  • Maven プロジェクトを読み込むことのできる IDE の場合、コード補完とタグライブラリのサポートが JSP で有効になります。

この設定を有効にするには、次の 2 つの処理が必要です。

  1. タグライブラリの依存関係を追加する
  2. Maven コンパイルプロセスの一環として JSP をコンパイルする

タグライブラリの依存関係の追加

以下に示す依存関係を content モジュールの POM に追加する必要があります。

注意:

AEM 製品の依存関係の読み込みで説明したように、製品の依存関係を読み込むのでない限り、依存関係の追加で説明した AEM 設定に一致するバージョンと共に依存関係を親 POM に追加する必要があります。以下の各エントリ内のコメントは、Dependency Finder で検索するパッケージを示しています。

注意:

com.adobe.granite.xssprotection アーティファクトは cq-quickstart-product-dependencies POM にインクルードされません。このアーティファクトには、Dependency Finder から取得されるすべての Maven コーディネートが必要です。

myproject/content/pom.xml

<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.jcr.jcr-wrapper</artifactId>
    <!-- javax.jcr -->
</dependency>
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.api</artifactId>
</dependency>
<dependency>
    <groupId>com.day.cq</groupId>
    <artifactId>cq-commons</artifactId>
    <!-- com.day.cq.commons -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-commons</artifactId>
    <!-- com.day.cq.wcm.commons -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-api</artifactId>
    <!-- com.day.cq.wcm.api -->
</dependency>
<dependency>
    <groupId>com.day.commons</groupId>
    <artifactId>day-commons-jstl</artifactId>
    <!-- javax.servlet.jsp.jstl.core -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-taglib</artifactId>
    <!-- com.day.cq.wcm.tags -->
</dependency>
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.scripting.jsp.taglib</artifactId>
    <!-- org.apache.sling.scripting.jsp.taglib -->
</dependency>
<dependency>
    <groupId>com.adobe.granite</groupId>
    <artifactId>com.adobe.granite.xssprotection</artifactId>
    <!-- com.adobe.granite.xss -->
</dependency>
<dependency>
    <groupId>com.day.cq.wcm</groupId>
    <artifactId>cq-wcm-core</artifactId>
    <!-- com.day.cq.wcm.core.components -->
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <!-- org.apache.commons.lang3 -->
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
</dependency>

Maven の compile フェーズの一環としての JSP のコンパイル

Maven の compile フェーズで JSP をコンパイルするために、Apache Sling の Maven JspC Plugin を以下のように使用します。

  • jspc ゴール(デフォルトで compile フェーズにバインドされるので、フェーズを明示的に指定する必要はありません)の実行を設定します。
  • ${project.build.directory}/jsps-to-compile 内の JSP をコンパイルするように指定します。
  • ${project.build.directory}/ignoredjspcmyproject/content/target/ignoredjspc に変換されます)に結果を出力します。
  • generate-sources フェーズで ${project.build.directory}/jsps-to-compile に JSP をコピーし、libs/ フォルダーをコピーしないように maven-resources-plugin を設定します(このフォルダーには AEM 製品コードが含まれているからです。また、プロジェクトでコンパイルの依存関係が生じないようにする必要があり、プラグインでコンパイルがおこなわれていることを検証する必要はないからです)。

前述のとおり、第 1 の目的は JSP を検証し、JSP にエラーが含まれている場合にビルドプロセスを失敗させることです。そのため、無視される(実際には後ですぐに削除される)個別のディレクトリに対して JSP をコンパイルします。

また、Maven JspC Plugin の結果を OSGi バンドルの一部としてバンドルおよびデプロイすることもできますが、これにより他の影響や副作用が生じ、JSP の検証という目的を逸脱してしまいます。

JSP からコンパイルされたクラスを削除するために、次に示すように Maven Clean Plugin を設定します。Maven JspC Plugin の結果を調べる場合は、myproject/contentmvn compile を実行します。その後、myproject/content/target/ignoredjspc で結果を確認します。

myproject/content/pom.xml

<build>
  <!-- ... -->
  <plugins>
    <!-- ... -->
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <executions>
        <execution>
          <id>copy-resources</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${project.build.directory}/jsps-to-compile</outputDirectory>
            <resources>
              <resource>
                <directory>src/main/content/jcr_root</directory>
                <excludes>
                  <exclude>libs/**</exclude>
                </excludes>
              </resource>
            </resources>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <groupId>org.apache.sling</groupId>
      <artifactId>maven-jspc-plugin</artifactId>
      <version>2.0.6</version>
      <executions>
        <execution>
          <id>compile-jsp</id>
          <goals>
            <goal>jspc</goal>
          </goals>
          <configuration>
            <jasperClassDebugInfo>false</jasperClassDebugInfo>
            <sourceDirectory>${project.build.directory}/jsps-to-compile</sourceDirectory>
            <outputDirectory>${project.build.directory}/ignoredjspc</outputDirectory>
          </configuration>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <artifactId>maven-clean-plugin</artifactId>
      <executions>
        <execution>
          <id>remove-compiled-jsps</id>
          <goals>
            <goal>clean</goal>
          </goals>
          <phase>process-classes</phase>
          <configuration>
            <excludeDefaultDirectories>true</excludeDefaultDirectories>
            <filesets>
              <fileset>
                <directory>${project.build.directory}/jsps-to-compile</directory>
                <directory>${project.build.directory}/ignoredjspc</directory>
              </fileset>
            </filesets>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

注意:

実際に /libs 内の JSP コードを利用する(このフォルダーから JSP をインクルードする)かどうかに応じて、コンパイル用にコピーする JSP を絞り込む必要があります。

例えば、/libs/foundation/global.jsp をインクルードする場合は、/libs を完全にスキップする前述の設定ではなく、次の設定を maven-resources-plugin に使用できます。

  <resource>  
      <directory>src/main/content/jcr_root</directory>  
      <includes>  
          <include>apps/**</include>  
          <include>libs/foundation/global.jsp</include>
    </includes>  
  </resource>  

SCM システムを使用する方法

ソース設定管理(SCM)を使用する場合は、次のことを確認する必要があります。

  • VCS がファイルシステム内のソース以外のアーティファクトを無視する
  • VLT が VCS のアーティファクトを無視し、それらをリポジトリにチェックインしない

注意:

この説明には、SCM を使用するように Maven を設定する方法は含まれていません。この方法について詳しくは、Maven の POM リファレンスおよび Maven SCM Plugin のドキュメントを参照してください。

SCM から除外するパターン

SCM から除外する一般的なパターンのリストを次に示します。例えば、git を使用する場合は、これらのパターンをプロジェクトの .gitignore ファイルに追加できます。

サンプルの .gitignore

# Ignore VLT files
.vlt
.vlt-sync.log
.vlt-sync-config.properties

# Ignore Quickstart launches in the source tree
license.properties
crx-quickstart

# Ignore compilation results
target

# Ignore IDE and Operating System artifacts
.idea
.classpath
.metadata
.project
.settings
maven-eclipse.xml
*.iml
*.ipr
*.iws
.DS_Store

VLT での SCM 制御ファイルの無視

リポジトリにチェックインしたくないコンテンツのソースツリーに SCM 制御ファイルが含まれている場合があります。

次の状況について考えてみましょう。

インストールしたバンドルの jar ファイルがファイルシステムに同期されないようにするために、アーキタイプでは既に .vltignore ファイルを作成済みです。

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar

当然、このファイルは SCM に追加したくないので、例えば git を使用する場合は、対応する .gitignore ファイルを追加します。

src/main/content/jcr_root/apps/myproject/install/.gitignore

*.jar

.gitignore ファイルをリポジトリに格納することはできないので、.gitignore ファイルをインクルードするように .vltignore ファイルを拡張する必要があります。

src/main/content/jcr_root/apps/myproject/install/.vltignore

*.jar
.gitignore

デプロイメントプロファイルを使用する方法

ビルドプロセスが大規模な開発ライフサイクル管理の設定(継続的インテグレーションプロセスなど)に含まれている場合は、開発者のローカルインスタンスだけではなく、他のマシンへのデプロイが必要になることが多くなります。

このようなシナリオでは、プロジェクトの POM に新しい Maven のビルドプロファイルを簡単に追加できます。

次に示す例では、integrationServer というプロファイルを追加します。このプロファイルでは、オーサーインスタンスとパブリッシュインスタンス用のホスト名とポートを再定義します。次に示すようにプロジェクトのルートから maven を実行して、これらのサーバーにデプロイできます。

# install on integration test author
$ mvn -PautoInstallPackage -PintegrationServer install

# install on integration test publisher
$ mvn -PautoInstallPackagePublish -PintegrationServer install

myproject/pom.xml

<profiles>

    <!-- ... -->
    
    <profile>
        <id>integrationServer</id>
        <properties>
            <crx.host>dev-author.intranet</crx.host>
            <crx.port>5502</crx.port>
            <publish.crx.host>dev-publish.intranet</publish.crx.host>
            <publish.crx.port>5503</publish.crx.port>
        </properties>
    </profile>
</profiles>

AEM Communities と連携する方法

AEM Communities 機能をライセンス許可するときは、追加の API jar が必要になります。

詳しくは、コミュニティに Maven を使用を参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー