Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

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

kautuk_sahni
Community Manager
Community Manager

BlogImage.jpg

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

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:

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.

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.

Topics

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

0 Replies