The AEM as a Cloud Service SDK is comprised of the following artifacts:
In addition, some customers who were previously deployed with AEM 6.5 or earlier versions will use the artifacts below. If local compilation is not working with the Quickstart jar and you suspect it is due to interfaces that have been removed from AEM deployed as a Cloud Service, reach out to Customer Support to determine if you need access. This will require changes in the backend.
The AEM as a Cloud Service SDK is used to build and deploy custom code. For further details, reference the AEM Project Archetype documentation. At a high level, the following steps are performed:
The same steps are executed by Cloud Manager when deploying to Cloud Environments. Performing builds locally allows for local development and testing so developers can efficiently discover code or structural issues well before committing to source control and triggering Cloud Manager deployments, which can take longer.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>aem-sdk-api</artifactId>
<version>2019.11.3006.20191108T223635Z-191201</version>
<scope>provided</scope>
</dependency>
The version entry for the SDK should match the version of AEM as a Cloud Service. You can see what version you are using by logging in to AEM, then going to the question mark in the top right corner of the screen and selecting About Adobe Experience Manager
When is it recommended to refresh the local project with a new SDK?
It is recommended to refresh it at least after a monthly maintenance release.
It is optional to refresh it after any daily maintenance release. Customers will be informed when their production instance has been successfully upgraded to a new AEM version. For the daily maintenance releases, it is not expected that the new SDK will have changed significantly, if at all. Still, it is recommended to occasionally refresh the local AEM developer environment with the latest SDK, then rebuild and test the custom application. The monthly maintenance release will typically include more impactful changes and thus developers should immediately refresh, rebuild, and test.
Below is the recommended procedure for refreshing a local environment:
crx-quickstart
folder to a different folder for safe keeping-r
).
If there is content that should be installed with each new AEM quickstart version, include it into a content package and in the project’s source control. Then, install it each time.
The recommendation is to update the SDK frequently (for example biweekly) and dispose full local state daily to not accidentally depend on stateful data in the application.
In case you depend on CryptoSupport (either by configuring the credentials of Cloudservices or the SMTP Mail service in AEM or by using CryptoSupport API in your application), the encrypted properties will be encrypted by a key that is autogenerated on the first start of an AEM environment. While the cloudsetup takes care of automatically reusing the environment-specific CryptoKey, it is necessary to inject the cryptokey into the local development environment.
By default AEM is configured to store the key data within the data folder of a folder, but for convenience of easier reuse in development, the AEM process can be initialized on first startup with “-Dcom.adobe.granite.crypto.file.disable=true
”. This will generate the encryption data at “/etc/key
”.
To be able to reuse content packages containing the encrypted values you need to follow these steps:
-Dcom.adobe.granite.crypto.file.disable=true
”. It is recommended, but optional, to always add it./etc/key
”. This will hold the secret to be reused across all environments for which you would want them to be reused/crx/de
to add it to the package that will be reused across installations