Adobe Experience Manager as a Cloud Service uses the principle of overlays to allow you to extend and customize the consoles and other functionality (for example, page authoring).
Overlay is a term that can be used in many contexts. In this context (extending AEM as a Cloud Service) an overlay means taking the predefined functionality and imposing your own definitions over that (to customize the standard functionality).
In a standard instance the predefined functionality is held under
/libs and it is recommended practice to define your overlay (customizations) under the
/apps branch (using a search path to resolve the resources).
The touch-enabled UI uses Granite-related overlays:
Reconstruct the appropriate
/libs structure under
This does not require a 1:1 copy, as the Sling Resource Merger is used to cross-reference the original definitions that are required. The Sling Resource Merger provides services to access and merge resources by means of diff (differencing) mechanisms.
Make any changes under
Overlays are the recommended method for many changes, such as configuring your consoles or creating your selection category to the asset browser in the side panel (used when authoring pages). They are required as:
You must not make changes in the
Any changes you do make may be lost, because this branch is liable to changes whenever upgrades are applied to your instance.
They concentrate your changes in one location; making it easier for you to track, migrate, backup and/or debug your changes as necessary.
AEM uses a search path to find a resource, searching (by default) first the
/apps branch and then the
/libs branch. This mechanism means that your overlay in
/apps (and the customizations defined there) will have priority.
For overlays the resource delivered is an aggregate of the resources and properties retrieved, depending on search paths defined in the OSGi configuration.