With the launch of Adobe Experience Manager (AEM) as a Cloud Service, Adobe has redefined the way content, code, and configurations are stored in AEM. The changes create a more explicitly structured project with strict enforcement, which translates to how AEM projects are set up and deployed. Let’s dive into the before and after pictures of that change, as well as providing reasoning for the changes in order to effectively deploy AEM as a Cloud Service.
For about a decade, 2009 to the beginning of 2019, we built and deployed CQ5/AEM content packages like this, where question marks, dashed lines, and cloudy boundaries indicate areas of ambiguity, non-determinism, and opportunities to become more proficient with the Felix Admin Console:
Diagram showing how CQ5/AEM content packages were built and deployed from 2009-2019
In the above diagram, we build two top-level content packages, herein labeled mixed, which is the new package type reserved for what is now the legacy approach to content package composition.
P1 could represent a base, or common content package created by a project team, and P2 might represent a content package that contains site- or brand-specific overlays and initial content. P1 also contains a subpackage, SUB1, which might represent the acs-aem-commons-content package of old, containing the project's OSGi bundles, UI templates and components, and other content dependencies.
The cloudy blobs labeled NODES LOL1, NODES LOLSUB1, and NODES LOL2 represent the context-agnostic DocView XML files included in each content package, masked by a hand-written filter.xml that might overwrite any repository path, including authorable content, OSGi bundles, and configurations, user nodes, group nodes, index definitions.