Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session

AEM Project Structure | AEM Community Discussion




AEM Project Structure by Adobe Docs


This article outlines the changes required to Adobe Experience Manager Maven projects to be AEM Cloud Service compatible by ensuring that they respect the split of mutable and immutable content; that requisite dependencies are established to create non-conflicting, deterministic deployments; and that they are packaged in a deployable structure.
AEM application deployments must be comprised of a single AEM package. This package should in turn contain sub-packages that comprise everything required by the application to function, including code, configuration and any supporting baseline content.

AEM requires a separation of content and code , which means a single content package cannot deploy to both /apps and runtime-writable areas (e.g. /content , /conf , /home , or anything not /apps ) of the repository. Instead, the application must separate code and content into discrete packages for deployment into AEM.
The package structure outlined in this document is compatible with both local development deployments and AEM Cloud Service deployments.

Mutable vs. Immutable Areas of the Repository
/apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts (i.e. at runtime). Any attempt to change an immutable area at runtime will fail.

Everything else in the repository, /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.

Read Full Blog

AEM Project Structure


Please use this thread to ask the related questions.

Kautuk Sahni

Topics help categorize Community content and increase your ability to discover relevant content.

0 Replies