Adobe Experience Manager(AEM)のローカル開発のセットアップに関するガイドです。ローカルインストール、Apache Maven、統合開発環境およびデバッグ/トラブルシューティングに関する重要なトピックについて説明します。Eclipse IDE、CRXDE Lite、Visual Studio Code および IntelliJ を使用した開発について説明します。
Adobe Experience Manager(AEM)向けの開発をするときの最初のステップは、ローカル開発環境のセットアップです。生産性を高め、より良いコードをより迅速に記述するために、時間をかけて質の高い開発環境をセットアップします。AEM のローカル開発環境は、次の 4 つの領域に分けることができます。
ローカル AEM インスタンスとは、開発者の個人用マシン上で動作している Adobe Experience Manager のコピーのことです。すべての AEM 開発は、ローカル AEM インスタンスに対してコードを記述し実行するところから始まります。
AEM を初めて使用する場合は、オーサーとパブリッシュという 2 つの基本的な実行モードをインストールできます。オーサー 実行モードは、デジタルマーケターがコンテンツの作成と管理に使用する環境です。開発時には、ほとんどの場合、オーサーインスタンスにコードをデプロイします。これにより、ページを作成し、コンポーネントを追加および設定できるようになります。AEM Sites は WYSIWYG オーサリング CMS なので、ほとんどの CSS と JavaScript をオーサーインスタンスに対してテストできます。
これは、ローカルのパブリッシュインスタンスに対する重要なテストコードでもあります。パブリッシュインスタンスは、web サイトの訪問者がやり取りを行う AEM 環境です。パブリッシュインスタンスはオーサーインスタンスと同じテクノロジースタックですが、設定と権限に関して大きな違いがあります。コードは、上位レベルの環境に昇格させる前に、ローカルのパブリッシュインスタンスに対してテストする必要があります。
~/aem-sdk
/author
/publish
QuickStart JAR を aem-author-p4502.jar に名称変更し、/author
ディレクトリの下に配置します。license.properties ファイルを /author
ディレクトリの下に追加します。
QuickStart JAR のコピーを作成し、aem-publish-p4503.jar に名称変更して、/publish
ディレクトリの下に配置します。license.properties ファイルのコピーを /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 は、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 も含まれています。
新しいプロジェクトを開始する際には、アーキタイプの最新バージョンを使用するのがベストプラクティスです。アーキタイプには複数のバージョンがあり、すべてのバージョンが以前のバージョンの AEM と互換性があるわけではないことに留意してください。
PATH
に追加されていることを確認します。
$ 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
以前は、nexus.adobe.com
を指定して AEM アーティファクトをダウンロードするために、adobe-public
Maven プロファイルを追加する必要がありました。すべての AEM アーティファクトは Maven Central を通じて利用できるようになり、adobe-public
プロファイルは必要なくなりました。
統合開発環境(IDE)は、テキストエディター、構文サポートおよびビルドツールを組み合わせたアプリケーションです。実施している開発のタイプによっては、ある IDE が別の IDE よりも望ましい場合があります。IDE に関係なく、テストのためにコードをローカル AEM インスタンスに定期的にプッシュできることが重要です。Git などのソース管理システムに保持するために、ローカル AEM インスタンスから AEM プロジェクトに設定を時々プルすることが重要です。
以下は、AEM 開発で使用される一般的な IDE のいくつかと、それぞれに対応するビデオです。ビデオでは、ローカル AEM インスタンスとの統合について説明しています。
WKND プロジェクトは、デフォルトで AEM as a Cloud Service で動作するように更新されました。6.5/6.4 との下位互換性を保つように更新されています。AEM 6.5 または 6.4 を使用している場合は、classic
プロファイルをすべての Maven コマンドに追加します。
$ mvn clean install -PautoInstallSinglePackage -Pclassic
IDE を使用する場合は、Maven プロファイルタブで classic
に必ずチェックを入れてください。
IntelliJ Maven プロファイル
Eclipse IDE は、Java™ 開発用の最も人気のある IDE の 1 つです。その主な理由は、オープンソースであり、無料であるからです。アドビでは、ローカル AEM インスタンスとコードを同期するための優れた GUI で開発しやすくするために、Eclipse 用のプラグイン AEM Developer Tools を提供しています。AEM Developer Tools が GUI をサポートいることもあり、AEM を初めて使用する開発者には Eclipse IDE をお勧めします。
IntelliJ IDEA は、プロフェッショナルな Java™ 開発のための強力な IDE です。IntelliJ IDEA には、無料の Community 版と商用(有料)の Ultimate 版の 2 種類があります。多くの AEM 開発には IntellIJ IDEA の無料の Community 版でも十分ですが、Ultimate 版ではその機能セットが拡張されています。
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 は、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 プラットフォームの問題と簡単に切り分けるためのものです。
すべてのバンドル(フラグメントを除く)はアクティブ状態になっている必要があります。コードバンドルがインストール済み状態の場合は、解決すべき問題があります。ほとんどの場合、それは依存関係の問題です。
上記のスクリーンショットでは、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 に基づいてビルドされているので、依存関係の問題が発生します。
AEM コンポーネントは、ビジネスロジックをカプセル化し、HTL レンダリングスクリプトがクリーンなままであることを保証するために、Sling Model をベースにする必要があります。Sling モデルが見つからないという問題が発生した場合は、コンソール(http://localhost:4502/system/console/status-slingmodels)で Sling Models を確認すると役に立つ場合があります。これにより、Sling モデルが登録されているかどうかと、モデルが関連付けられているリソースタイプ(コンポーネントパス)がわかります。
wknd/components/content/byline
というコンポーネントリソースタイプに関連付けられている Sling Model である BylineImpl
の登録を示します。
CSS や JavaScript のほとんどの問題については、ブラウザーの開発ツールを使用することが、最も効果的なトラブルシューティング方法です。AEM オーサーインスタンスに対して開発する際の問題を絞り込むには、「公開済みとして」ページを表示すると便利です。
ページプロパティメニューを開き、「公開済みとして表示」をクリックします。これにより、AEM エディターを含まず、クエリパラメーターが wcmmode=disabled に設定されたページが開きます。これにより、AEM オーサリング UI が効果的に無効になり、フロントエンドの問題のトラブルシューティングやデバッグがはるかに容易になります。
フロントエンドコードを開発するときによく発生するもう 1 つの問題は、古い CSS や JS が読み込まれることです。最初の手順として、ブラウザー履歴がクリアされていることを確認し、必要に応じて匿名ブラウザーまたは新しいセッションを開始します。
複数のクライアントライブラリを組み込むために、カテゴリや埋め込みの様々な方法を使用すると、トラブルシューティングが面倒になります。AEM では、そのような場合に役立つツールをいくつか公開しています。最も重要なツールの 1 つは、クライアントライブラリの再ビルドです。これにより、AEM はすべての LESS ファイルを強制的に再コンパイルし、CSS を生成します。
クライアントライブラリの再ビルドツールを使用して、絶えずキャッシュを無効化する必要がある場合は、すべてのクライアントライブラリを 1 回再ビルドするだけの価値があるかもしれません。この処理には約 15 分かかりますが、実行すれば、通常は、今後発生する可能性のあるキャッシュの問題が解消されます。