The Ultimate Guide to AD0-E102 Adobe Experience Manager Sites Business Practitioner

The Ultimate Guide to AD0-E102 Adobe Experience Manager Sites Business Practitioner AD0-E102 Adobe Experience Manager Sites Business Practitioner Certification Exam Credential.

If other AEM projects, which are themselves comprised of their own code and content packages, are used by the AEM deployment, their container packages should be embedded in the project’s all package.

For example, an AEM project that includes 2 vendor AEM applications might look like:

all content package embeds the following packages, to create a singular deployment artifact core OSGi bundle Jar required by the AEM application ui.apps deploys code required by the AEM application ui.config deploys OSGi configurations required by the AEM application ui.content deploys content and configuration required by the AEM application vendor-x.all deploys the everything (code and content) required by the vendor X application vendor-y.all deploys the everything (code and content) required by the vendor Y application Package Types Packages are to be marked with their declared package type.

Container packages must set their packageType to container. Container packages must not directly contain OSGi bundles, OSGi configurations and are not allowed to use install hooks.

Code (immutable) packages must set their packageType to application.

Content (mutable) packages must set their packageType to content.

For more information see Apache Jackrabbit FileVault - Package Maven Plugin documentation and the FileVault Maven configuration snippet below.

TIP See the POM XML Snippets section below for a complete snippet.

Marking Packages for Deployment by Adobe Cloud Manager

By default, Adobe Cloud Manager harvests all packages produced by the Maven build, however since the container (all) package is the singular deployment artifact that contains all code and content packages, we must ensure only the container (all) package is deployed. To ensure this, other Packages the Maven build generates must be marked with the FileVault Content Package Maven Plug-In configuration of <properties><cloudManagerTarget>none</cloudManageTarget></properties>.

TIP See the POM XML Snippets section below for a complete snippet.

Repo Init Repo Init provides instructions, or scripts, that define JCR structures, ranging from common node structures like folder trees, to users, service user, groups and ACL definition.

The key benefits of Repo Init are they have implicit permissions to perform all actions defined by their scripts, and are invoked early in the deployment lifecycle ensuring all requisite JCR structures exist by the time code is executed.

While Repo Init scripts themselves live in the ui.config project as scripts, they can, and should, be used to define the following mutable structures:

Baseline content structures Service Users Users Groups ACLs Repo Init scripts are stored as scripts entries of RepositoryInitializer OSGi factory configurations, and thus, can be implicitly targeted by run mode, allowing for differences between AEM Author and AEM Publish Services’ Repo Init scripts, or even between environments (Dev, Stage and Prod).

Repo Init OSGi configs are best written in the .config OSGi configuration format as they support multilines, which is an exception to the best practices of using .cfg.json to define OSGi configurations.

Note that when defining Users, and Groups, only groups are considered part of the application, and integral to its function should be defined here. Organization Users and Groups should still be defined at runtime in AEM; for example, if a custom workflow assigns work to a named Group, that Group should