Page Comparison

...

In case you are using ACS AEM Commons in your project you have to update the package references to differentiate between the immutable and mutable content parts of ACS Commonsand update to latest version (6.0.x or above):

• In the parent POM, replace the reference to com.adobe.acs:acs-aem-commons-content with:

  Code Block
  language xml
  <dependency> <groupId>com.adobe.acs</groupId> <artifactId>acs-aem-commons-ui.apps<all</artifactId> <version>${acs.aem.commons.version}</version> <classifier>min</classifier> <type>zip</type> </dependency> <dependency> <groupId>com.adobe.acs</groupId> <artifactId>acs

• In the config-definition POM, replace the reference to com.adobe.acs:acs-aem-commons-

  ui.content</artifactId> <version>${acs.aem.commons.version}</version> <classifier>min</classifier> <type>zip</type>

  contentwith:

  Code Block
  language xml
  <dependency> <groupId>com.adobe.acs</groupId> <artifactId>acs-aem-commons-all</artifactId> <type>zip</type> <scope>compile</scope> </dependency>

• In the CONGA role in config-definition POM/src/main/roles, replace the reference to com.adobe.acs:acs-aem-commons-content with:

  Code Block
  language xml
  <dependency> <groupId>com- url: url: mvn:com.adobe.acs</groupId> <artifactId>acsacs/acs-aem-commons-ui.apps</artifactId> <classifier>min</classifier>all//zip <type>zip</type> <scope>compile</scope> </dependency> <dependency> <groupId>com.adobe.acs</groupId> <artifactId>acs-aem-commons-ui.content</artifactId> <classifier>min</classifier> <type>zip</type> <scope>compile</scope> </dependency>

• In the CONGA role in config-definition/src/main/roles, replace the reference to com.adobe.acs:acs-aem-commons-content with:

  Code Block
  - url: mvn:com.adobe.acs/acs-aem-commons-ui.apps//zip/min dir: packages postProcessorOptions: contentPackage.packageType: application - url: mvn:com.adobe.acs/acs-aem-commons-ui.content//zip/min dir: packages postProcessorOptions: contentPackage.packageType: content

...

• dir: packages

Step 3: Enable reproducible builds in Maven

...

The latest version of AEM Core Components is already included in the AEM SDK API and AEM Cloud Service, it’s not longer required to reference it as explicit dependency or deploy the packages together with your project:

1. Remove all references to com.adobe.cq:core.wcm.components.core and com.adobe.cq:core.wcm.components.all from your parent POM.

2. Remove all references to com.adobe.cq:core.wcm.components.core from your bundle POMs.

3. Remove all references to com.adobe.cq:core.wcm.components.all from the config-definition POM, and remove the reference to it from the CONGA Roles at config-definition/src/main/roles.

Step 8: Create service users via repoinit

...

Check/adapt all your content package module POMs:

1. Make sure the appropriate packageType property is set for each content package. “application” and “container” are immutable content packages, “content” are mutable content packages. It’s not allowed to use the “mixed” type. Example:

   Code Block
   language xml
   <packageType>content</packageType>

2. If you have packages that mix immutable and mutable content (the validation rules of the FileVault Package Maven Plugin will tell you that), you have to split up your packages.

3. Make sure that all packages have a new package property cloudManagerTarget set to none. This instructs the Cloud Manager to ignore this package - it will be handed over to the Cloud Manager as part of an “all” package generated by CONGA in a later step. Example:

   Code Block
   language xml
   <!-- Do not deploy directly via AEM cloud manager, only as part of CONGA-generated "all" package --> <properties> <cloudManagerTarget>none</cloudManagerTarget> </properties>

4. You do not have to declare dependencies between your packages. This is done by CONGA automatically based on the order of the files defined in the CONGA role.

5. It is recommended (but not mandatory) to create a “repository structure” package module that defines all application folders that are already present OOTB in AEM Cloud Service and which should not fail the validation of the other packages if application content is deployed to them. In the Adobe documentation this module is referenced as repository-structure, in the latest Adobe AEM project archetypes it’s named ui.apps.structure.

   • For CONGA-bases projects the recommendation is to create it at

     Code Block
     content-packages/apps-repository-structure/pom.xml

   • Example package definition (full example):

     Code Block
     language xml
     <plugin> <groupId>org.apache.jackrabbit</groupId> <artifactId>filevault-package-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <!-- Do not deploy directly via AEM cloud manager, only as part of CONGA-generated "all" package --> <properties> <cloudManagerTarget>none</cloudManagerTarget> </properties> <filters> <!-- /apps root --> <filter><root>/apps</root></filter> <!-- Common overlay roots --> <filter><root>/apps/sling</root></filter> <filter><root>/apps/cq</root></filter> <filter><root>/apps/dam</root></filter> <filter><root>/apps/wcm</root></filter> <filter><root>/apps/msm</root></filter> <!-- Immutable context-aware configurations --> <filter><root>/apps/settings</root></filter> </filters> </configuration> </plugin>

   • Once this is defined it can be referenced from the other content package modules containing immutable application content of the project. Example:

     Code Block
     language xml
     <dependencies> <dependency> <groupId>YOUR_GROUP_ID</groupId> <artifactId>YOUR_GROUP_ID.apps-repository-structure</artifactId> <version>YOUR_VERSION</version> <type>zip</type> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.jackrabbit</groupId> <artifactId>filevault-package-maven-plugin</artifactId> <extensions>true</extensions> <configuration> ... <repositoryStructurePackages> <repositoryStructurePackage> <groupId>YOUR_GROUP_ID</groupId> <artifactId>YOUR_GROUP_ID.apps-repository-structure</artifactId> </repositoryStructurePackage> </repositoryStructurePackages> </configuration> </plugin> </plugins> </build>

   • Make sure this package gets never deployed to any AEM instance! It’s only a tool for supporting the package validation during build time.

Step 11: Make CONGA-generated content packages compatible with AEM Cloud

...

The way recommended by Adobe is to put the AEM application code directly in the GIT repository provided by the Cloud Manager. In this case no separate “configuration-management” GIT repository is used, so we need to define an additional CONGA Environment for the AEM cloud dev/stage/prod environments. Create a CONGA environment directly in the application GIT repository at config-definition/src/main/dev-environments:

1. Define a new “cloud” environment:

   • Copy the https://github.com/wcm-io/wcm-io-maven-archetype-aem/blob/develop/src/main/resources/archetype-resources/config-definition/src/main/dev-environments/cloud.yaml template from the archetype and remove the velocity statements (#set, #if..#end)

   • Replace the variables ${projectName} and ${packageGroupNames}

   • Validate the root/redirect paths in the dispatcher/tenant configuration

   • Consider to use the cloudManagerConditional configuration option instead of the simplified serverName/serverAlias definition to define the host names for each cloud environment

2. Rename the predefined “development” environment to “local” to avoid confusion with the cloud “dev” environment. For this you have to:

   • Rename the file development.yaml to local.yaml

   • Change the references to the “development” CONGA_ENVIRONMENT in the configuration/definition/packages-upload.sh and build-deploy.sh scripts to “local”

3. Mark this “local” environment to be ignored by the Cloud Manager (it’s only used for local AEM deployment) by adding to the config: section:

   Code Block
   # Not used for AEM cloud cloudManager.target: - none

The rationale behind this:

...