Content Package Type Validation Forces Rethink of Standard Project Structure for Adobe Experience ManagerADOBE EXPERIENCE MANAGER | AEM Community Blog Seeding

[kautuk_sahni]

Content Package Type Validation Forces Rethink of Standard Project Structure for Adobe Experience Ma... by Mark Adamcin

Abstract

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.

Prehistoric FileVault
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.

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.

Read Full Blog

Content Package Type Validation Forces Rethink of Standard Project Structure for Adobe Experience Ma...

Q&A

Please use this thread to ask the related questions.