...
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
ui.content</artifactId> <version>${acs.aem.commons.version}</version> <classifier>min</classifier> <type>zip</type>com.adobe.acs:acs-aem-commons-
content
with: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 tocom.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 tocom.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:
Remove all references to
com.adobe.cq:core.wcm.components.core
andcom.adobe.cq:core.wcm.components.all
from your parent POM.Remove all references to
com.adobe.cq:core.wcm.components.core
from your bundle POMs.Remove all references to
com.adobe.cq:core.wcm.components.all
from theconfig-definition
POM, and remove the reference to it from the CONGA Roles atconfig-definition/src/main/roles
.
Step 8: Create service users via repoinit
...
Check/adapt all your content package module POMs:
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>
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.
Make sure that all packages have a new package property
cloudManagerTarget
set tonone
. 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>
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.
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 namedui.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
:
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 simplifiedserverName
/serverAlias
definition to define the host names for each cloud environment
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
tolocal.yaml
Change the references to the “development” CONGA_ENVIRONMENT in the
configuration/definition/packages-upload.sh
andbuild-deploy.sh
scripts to “local”
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:
...