Repository Structure

Let’s talk about repository structure.

When you start server and open CRXDE Lite you see the structure of the repository, let’s take a look at their purposes of each folder.

1. /apps folder: Is an application container, where you will be able to store all components and OSGi configuration definition specific to your application.
2. /content folder: contains content created for your website, pages with components, and additional information for your site. Also this folder can contain a user generated content.
3. /conf: is the place where configurations are stored such as content aware configurations or some cloud configurations, they also store editable template definitions and there instances, and custom workflows as well.
4. /etc folder: initialization and configuration information. It usually stores global JS libraries and CSS or less files.
5. /libs: is a folder where you can find standard components and the libraries for dialogs you should not change anything in the libs path.
6. /oak:index: is a structure for definitions for Lucene and Property indexes for fast lookup and search by your repository.

Note: Starting from AEM 6.4 static templates are not considered to be best practices so you should use Editable Template instead which has stored under conf.

Now pay attention Adobe has decided to move away from using etc and eventually deprecate any use of the directory starting from AEM 6.4.

AEM Customization Framework

On the above picture you can see AEM Customization Framework- a new feature of AEM 6.4. The framework consist of 2 parts

1. API surface
2. Content classifications

Let’s take a look at them

API surface from AEM 6.4, AEM bundles are not supposed to be used by a customer with marked as a private or public this has nothing to do with Java private protected or public modifiers.

Content classifications: Up to AEM 6.4, good fashion of overriding out-of-the-box-functionality with using Sling Resource Merger- this used to be achieved through copying node structure of desired components in libs to apps.

Sling Resource Merger took care of resolution this was introduced in sake of sustainability those still produce number of issues because changes under libs are an avoidable, seeing all that Adobe has decided to mark specific path under libs with classificator’s that will help developer understand consequences of component customization, these classificator’s are

1. Public: save to overlay, inherit or use directly through a property.
2. Abstract: save to overlay, inherit but couldn’t be used directly.
3. Final: cannot be overplayed or inherited, still could be used directly.
4. Internal: No actions allowed at all.