With AEM as a Cloud Service receiving regular, automated updates, it is important to keep the SDK for local development up to date. If you're using GitHub, Dependabot can help you keep up with just a few lines of config. Let's see how.
For anyone who remembers the ceremony around installing AEM Service Packs and Cumulative Feature Packs, the always-up-to-date approach in AEMaaCS is quite refreshing indeed. Instead of big-bang changes surrounded by days or weeks of testing, we get a constant stream of larger and smaller changes to the CMS. It does, however, mean that we, as developers, need to keep up with the changes. Otherwise, we risk developing and testing against a version of the product that isn't actually there in production any more.
With every major change in AEMaaCS, a new version of the SDK becomes available in the Software Distribution portal, and it's a good habit to use the latest version available.
At VML, we have a large community of AEM developers and we've got our ways of staying current. While Adobe's Software Distribution portal is quite convenient, as a go-to place for downloads, it doesn't, to my knowledge, come with an API that would make the tracking of software and library versions being released easier.
As a broader community, we currently keep up with the updates by running daily a GitHub Action, which connects to the portal and processes the web UI using Playwright. If it finds a new version it sends a notification to a dedicated Slack channel. It does the job, which is all that really matters to us in this context. Because it's coded in a somewhat hacky way and prone to breaking in case the UI of the Software Distribution portal changes, it's not something we would open-source, or recommend.
However, as I've recently learned, there's a super easy way to get partway there, and with just a dozen lines of YAML... as long as you use GitHub, which we currently do for most of our projects.
The trick is to use Dependabot. While it's primarily a security tool that flags vulnerabilities, suggests updates and improves supply chain security, we can set it up to help with our little use case.
The first time I heard of Dependabot, it was in the context of Node/JavaScript/TypeScript codebases. It may come as a surprise to some that it supports a wide array of package managers, and it is highly configurable.
Assuming you're keeping an AEMaaCS project (based on the official archetype) under version control on GitHub, and that you've got Dependabot enabled, here's how you can have it scan Maven dependencies.
- Find or create a
.github
folder at the root of your repository. This is likely to exist if you've got any GitHub Workflows or aCODEOWNERS
file provided. - Create a new file, named
dependabot.yml
. This isn't a prerequisite for running Dependabot, but we'll use it to have it analyze Maven dependencies. - Fill the file with the code shown below:
version: 2
updates:
- package-ecosystem: npm
directory: /
schedule:
interval: daily
commit-message:
prefix: "npm"
versioning-strategy: auto
- package-ecosystem: maven
directory: /
schedule:
interval: daily
commit-message:
prefix: "maven"
Most, if not all AEM projects will be mixed codebases of front-end and back-end code. That's why we've got two package ecosystems listed. One should take care of our clientlib/theme build scripts, and the other one will take care of back-end dependencies. While it doesn't actually run Maven at any point, it suggests updates to dependencies listed in the pom.xml
files in your repository.
In the <properties>
of the root pom.xml
file, there's a custom element of <aem.sdk.api>
which contains the exact version of the SDK, which is then listed as the very first dependency in that same Project Object Model.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>aem-sdk-api</artifactId>
<version>${aem.sdk.api}</version>
<scope>provided</scope>
</dependency>
This ensures the project is built against the same library versions as the ones available in AEMaaCS. Dependabot recognises this as a dependency version and it will automatically raise a Pull Request on GitHub when it detects that a newer version is available.
If you should choose to ignore this PR long enough, Dependabot will be smart enought to close it and open a new one as soon as the newer version of the SDK (or indeed, any artifact) becomes available.
Dependabot can also automatically build your project, and run tests, based on any GitHub workflows you might have defined and assigned to your Pull Requests. It will also propose changes to other Maven dependencies, which is an added bonus, if you're just enabling it to get notifications about the SDK :)
Next, you'll want to head to the Software Distribution portal, download the SDK and make sure your local setup works as expected with the latest dependencies.
Here's a list of steps to follow if you're just using the JAR as-is. And hey, if you want to save yourself some effort and automate some of those steps, have a look at AEM Compose.