ローカル AEM 開発環境のセットアップ

Adobe Experience Manager（AEM）のローカル開発のセットアップに関するガイドです。ローカルインストール、Apache Maven、統合開発環境およびデバッグ／トラブルシューティングに関する重要なトピックについて説明します。Eclipse IDE、CRXDE Lite、Visual Studio Code および IntelliJ を使用した開発について説明します。

概要

Adobe Experience Manager（AEM）向けの開発をするときの最初のステップは、ローカル開発環境のセットアップです。生産性を高め、より良いコードをより迅速に記述するために、時間をかけて質の高い開発環境をセットアップします。AEM のローカル開発環境は、次の 4 つの領域に分けることができます。

ローカル AEM インスタンスのインストール

ローカル AEM インスタンスとは、開発者の個人用マシン上で動作している Adobe Experience Manager のコピーのことです。すべて ​の AEM 開発は、ローカル AEM インスタンスに対してコードを記述し実行するところから始まります。

AEM を初めて使用する場合は、オーサー ​と​ パブリッシュ ​という 2 つの基本的な実行モードをインストールできます。オーサー 実行モードは、デジタルマーケターがコンテンツの作成と管理に使用する環境です。開発時には、ほとんどの場合、オーサーインスタンスにコードをデプロイします。これにより、ページを作成し、コンポーネントを追加および設定できるようになります。AEM Sites は WYSIWYG オーサリング CMS なので、ほとんどの CSS と JavaScript をオーサーインスタンスに対してテストできます。

これは、ローカルの​ パブリッシュ ​インスタンスに対する​ 重要な ​テストコードでもあります。パブリッシュ ​インスタンスは、web サイトの訪問者がやり取りを行う AEM 環境です。パブリッシュ ​インスタンスは​ オーサー ​インスタンスと同じテクノロジースタックですが、設定と権限に関して大きな違いがあります。コードは、上位レベルの環境に昇格させる前に、ローカルの​ パブリッシュ ​インスタンスに対してテストする必要があります。

手順

~/aem-sdk
    /author
    /publish

~/aem-sdk
    /author
        + aem-author-p4502.jar
        + license.properties
    /publish
        + aem-publish-p4503.jar
        + license.properties

aem-publish-p4503.jar ファイルをダブルクリックして、パブリッシュ ​インスタンスをインストールします。これにより、ローカルコンピューターのポート 4503 で動作するパブリッシュインスタンスが起動します。

コマンドラインの使用

JAR ファイルをダブルクリックする代わりに、コマンドラインから AEM を起動するか、ローカルオペレーティングシステムの種類に応じてスクリプト（.bat または .sh）を作成することもできます。サンプルコマンドの例を以下に示します。

$ java -Xmx2048M -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=30303 -jar aem-author-p4502.jar -gui -r"author,localdev"

ここで、-X は JVM オプションで、-D は追加のフレームワークプロパティです。詳しくは、AEM インスタンスのデプロイと保守およびクイックスタートファイルから使用できるその他のオプションを参照してください。

Apache Maven のインストール

Apache Maven は、Java ベースのプロジェクトのビルドおよびデプロイ手順を管理するツールです。AEM は Java ベースのプラットフォームであり、Maven は AEM プロジェクトのコードを管理する標準的な方法になります。AEM Maven プロジェクト ​または単に AEM プロジェクト と言う場合、サイトのすべての​ カスタム ​コードを含む Maven プロジェクトのことを指しています。

すべての AEM プロジェクトは、AEM Project Archetype の最新バージョン（https://github.com/adobe/aem-project-archetype）に基づいて構築する必要があります。AEM Project Archetype には、サンプルのコードとコンテンツを含んだ AEM プロジェクトのブートストラップが用意されています。AEM Project Archetype には、プロジェクトで使用するように設定された AEM WCM Core Components も含まれています。

手順

$ mvn --version
Apache Maven 3.3.9
Maven home: /Library/apache-maven-3.3.9
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8

統合開発環境のセットアップ

統合開発環境（IDE）は、テキストエディター、構文サポートおよびビルドツールを組み合わせたアプリケーションです。実施している開発のタイプによっては、ある IDE が別の IDE よりも望ましい場合があります。IDE に関係なく、テストのためにコードをローカル AEM インスタンスに定期的に​ プッシュ ​できることが重要です。Git などのソース管理システムに保持するために、ローカル AEM インスタンスから AEM プロジェクトに設定を時々​ プル ​することが重要です。

以下は、AEM 開発で使用される一般的な IDE のいくつかと、それぞれに対応するビデオです。ビデオでは、ローカル AEM インスタンスとの統合について説明しています。

$ mvn clean install -PautoInstallSinglePackage -Pclassic

IDE を使用する場合は、Maven プロファイルタブで classic に必ずチェックを入れてください。

IntelliJ Maven プロファイル

Eclipse IDE

Eclipse IDE は、Java™ 開発用の最も人気のある IDE の 1 つです。その主な理由は、オープンソースであり、無料 ​であるからです。アドビでは、ローカル AEM インスタンスとコードを同期するための優れた GUI で開発しやすくするために、Eclipse 用のプラグイン AEM Developer Tools を提供しています。AEM Developer Tools が GUI をサポートいることもあり、AEM を初めて使用する開発者には Eclipse IDE をお勧めします。

インストールとセットアップ

IntelliJ IDEA

IntelliJ IDEA は、プロフェッショナルな Java™ 開発のための強力な IDE です。IntelliJ IDEA には、無料 ​の Community 版と商用（有料）の Ultimate 版の 2 種類があります。多くの AEM 開発には IntellIJ IDEA の無料の Community 版でも十分ですが、Ultimate 版ではその機能セットが拡張されています。

Installation and Setup

Visual Studio Code

Visual Studio Code は、JavaScript サポートの強化版である Intellisense とブラウザーデバッグのサポートにより、すぐに​ フロントエンド開発者 ​のお気に入りのツールになりました。Visual Studio Code は、多くの強力な拡張機能を備えた無料のオープンソースです。Visual Studio Code は、アドビのツール repo を使用して、AEM と連携するようにセットアップできます。 コミュニティでサポートしているいくつかの拡張機能をインストールして AEM と統合することもできます。

Visual Studio Code は、主に CSS／LESS や、AEM クライアントライブラリを作成するための JavaScript コードを記述するフロントエンド開発者に最適です。ただし、このツールは、ノード定義（ダイアログ、コンポーネント）を生の XML で編集する必要があるので、AEM を初めて使用する開発者には最適でない可能性があります。Visual Studio Code で使用できる Java™ 拡張機能はいくつかありますが、主に Java™ 開発を行う場合は、Eclipse IDE または IntelliJ が望ましいでしょう。

重要なリンク

CRXDE Lite

CRXDE Lite は、AEM リポジトリのブラウザーベースのビューです。CRXDE Lite は AEM に組み込まれており、開発者はこれを使用して、ファイルの編集や、コンポーネント、ダイアログおよびテンプレートの定義など、標準的な開発タスクを実行できます。CRXDE Lite は完全な開発環境を意図したものでは​ ありません ​が、デバッグツールとして効果的です。CRXDE Lite は、コードベース外の製品コードを拡張したり、単に理解したりする場合に便利です。CRXDE Lite は、リポジトリの強力なビューを提供し、権限を効果的にテストおよび管理する手段となります。

CRXDE Lite は、他の IDE と一緒に使用してコードのテストとデバッグを行うべきものであり、主要な開発ツールとして使用しないでください。構文のサポートに制限があり、オートコンプリート機能はなく、ソース管理システムとの統合も制限されています。

トラブルシューティング

助けて。 コードが動作しません。どのような開発でも、コードが期待どおりに動作しないことは（おそらくよく）あります。AEM は強力なプラットフォームですが、強力であればあるほど、複雑さも増します。以下は、問題のトラブルシューティングとトラッキングを行う際の概要です（ただし、問題が発生する可能性がある事項を網羅したものではありません）。

コードのデプロイメントの検証

問題が発生した場合の最初のステップは、コードが AEM に正常にデプロイされインストールされていることを確認することです。

ログの確認

AEM は情報提供の充実したプラットフォームであり、error.log に有用な情報を記録しています。error.log は、AEM がインストールされている場所にあります（<aem-installation-folder>/crx-quickstart/logs/error.log）。

問題を追跡するための有効な手法は、Java™ コードにログステートメントを追加することです。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...

public class MyClass {
    private final Logger log = LoggerFactory.getLogger(getClass());

    ...

    String myVariable = "My Variable";

    log.debug("Debug statement of myVariable {}", myVariable);

    log.info("Info statement of myVariable {}", myVariable);
}

デフォルトでは、error.log は INFO ステートメントをログに記録するように設定されています。ログレベルを変更したい場合は、ログサポート（http://localhost:4502/system/console/slinglog）に移動して変更できます。また、error.log に含まれている情報が多すぎると感じることもあるかもしれません。その場合は、ログサポートを使用して、指定した Java™ パッケージのみのログステートメントを設定することができます。これはプロジェクトのベストプラクティスの 1 つで、カスタムコードの問題を OOTB AEM プラットフォームの問題と簡単に切り分けるためのものです。

バンドルはインストール済み状態です bundle-active

すべてのバンドル（フラグメントを除く）は​ アクティブ ​状態になっている必要があります。コードバンドルがインストール済み状態の場合は、解決すべき問題があります。ほとんどの場合、それは依存関係の問題です。

上記のスクリーンショットでは、WKND Core bundle はインストール済み状態です。これは、AEM インスタンスで使用可能なバージョンとは異なるバージョンの com.adobe.cq.wcm.core.components.models をバンドルが想定しているからです。

使用できる便利なツールは、依存関係ファインダー（http://localhost:4502/system/console/depfinder）です。AEM インスタンスで使用可能なバージョンを調べるには、Java™ パッケージ名を追加します。

上記の例を続けると、AEM インスタンスにインストールされているバージョンが、バンドルが想定していた 12.6 ではなく、12.2 であることがわかります。そこからさかのぼって、AEM での Maven 依存関係が AEM プロジェクトの Maven 依存関係と一致するかどうかを確認できます。上記の例では、Core Components v2.2.0 は AEM インスタンスにインストールされていますが、コードバンドルは v2.2.2 に基づいてビルドされているので、依存関係の問題が発生します。

Sling モデルの登録の検証 osgi-component-sling-models

AEM コンポーネントは、ビジネスロジックをカプセル化し、HTL レンダリングスクリプトがクリーンなままであることを保証するために、Sling Model をベースにする必要があります。Sling モデルが見つからないという問題が発生した場合は、コンソール（http://localhost:4502/system/console/status-slingmodels）で Sling Models を確認すると役に立つ場合があります。これにより、Sling モデルが登録されているかどうかと、モデルが関連付けられているリソースタイプ（コンポーネントパス）がわかります。

wknd/components/content/byline というコンポーネントリソースタイプに関連付けられている Sling Model である BylineImpl の登録を示します。

CSS または JavaScript の問題

CSS や JavaScript のほとんどの問題については、ブラウザーの開発ツールを使用することが、最も効果的なトラブルシューティング方法です。AEM オーサーインスタンスに対して開発する際の問題を絞り込むには、「公開済みとして」ページを表示すると便利です。

ページプロパティメニューを開き、「公開済みとして表示」をクリックします。これにより、AEM エディターを含まず、クエリパラメーターが wcmmode=disabled に設定されたページが開きます。これにより、AEM オーサリング UI が効果的に無効になり、フロントエンドの問題のトラブルシューティングやデバッグがはるかに容易になります。

フロントエンドコードを開発するときによく発生するもう 1 つの問題は、古い CSS や JS が読み込まれることです。最初の手順として、ブラウザー履歴がクリアされていることを確認し、必要に応じて匿名ブラウザーまたは新しいセッションを開始します。

クライアントライブラリのデバッグ

複数のクライアントライブラリを組み込むために、カテゴリや埋め込みの様々な方法を使用すると、トラブルシューティングが面倒になります。AEM では、そのような場合に役立つツールをいくつか公開しています。最も重要なツールの 1 つは、クライアントライブラリの再ビルドです。これにより、AEM はすべての LESS ファイルを強制的に再コンパイルし、CSS を生成します。