The AEM as a Cloud Service SDK is composed of the following artifacts:
In addition, some customers who were previously deployed with AEM 6.5 or earlier versions use the artifacts below. If local compilation is not working with the Quickstart jar, and you suspect it is from the removal of interfaces from AEM deployed as a Cloud Service, contact Customer Support. They can determine if you need access. It requires changes in the backend.
The AEM as a Cloud Service SDK is used to build and deploy custom code. See 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. Developers can efficiently discover code or structural issues before committing to source control and triggering Cloud Manager deployments, which can take longer.
The AEM as a Cloud Service SDK should be built with a distribution and version of Java supported by Cloud Manager’s build environment. AEM as a Cloud Service customers may download the Oracle JDK from the Software Distribution portal and have Java 11 Extended Support until September 2026 due to Adobe’s licensing and support terms for the Oracle Java technology when used in Adobe Experience Manager projects.
<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 on to AEM. In the upper-right corner of the screen, go to the question mark and select About Adobe Experience Manager.
When is it recommended to refresh the local project with a new SDK?
Adobe recommends refreshing it after a monthly maintenance release.
It is optional to refresh it after any daily maintenance release. Customers are 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 has 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 typically includes 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.
If you depend on CryptoSupport (either by configuring the credentials of Cloud services or the SMTP Mail service in AEM or by using CryptoSupport API in your application), the encrypted properties are encrypted by a key. This key is autogenerated on the first start of an AEM environment. While the cloud setup 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 process generates the encryption data at “/etc/key
”.
To be able to reuse content packages that contain the encrypted values, follow these steps:
-Dcom.adobe.granite.crypto.file.disable=true
”. It is recommended, but optional, to always add it./etc/key
”. This package holds the secret to be reused across all environments for which you would want them to be reused./crx/de
so you can add it to the package that is reused across installations.