AEM CS API deprecations

You might have received alerts already, that your application is using deprecated APIs, and that you should act now. Many of these warnings are out there for quite a bit of time, but have never been enforced. Looks like now it’s the time.

As I handled a few of these cases and warnings already, a few words to them.

Use the aemanalyser-maven-plugin

To speedup the feedback cycle, use the aemanalyser-maven-plugin to perform the same validation the fullstack pipeline would do. Execute the following steps to make it work:

• Add a dependency to the aemanalyser-maven-plugin to your all/pom.xml. Make sure that you are using the latest version 1.6.16.
• Configure it to execute the project-analyse goal (also in the all/pom.xml); see here how it’s done the AEM archetype

Strictly speaking this is not necessary in the context of the API deprecation process, but having it will make your life much easier.

Update ACS AEM Commons

ACS AEM Commons is a library which is used by many AEM CS customers. Updating it to the version 6.11.0 (or later) makes all warnings go away. Just make sure that you use the “cloud” classifier. And if you are still referencing or embedding the “twitter” module, remove it, as it has not been update for a long time, and I doubt that it is still working.

Guava

If you have a reference to the use of the deprecated API packages “com.google.*”, these are caused by the upcoming removal of Guava from the AEM public API. While the official documentation mentions to use the latest Guava version, this is most often not necessarily working. Instead use the version 15.0 as a short-term solution. (Guava changes public API quite often, and for that newer versions are often not compatible.)

To make that work:

• add a dependency to Guava 15 into your all/pom.xml file.
• add an additional <embed> statement to the filevault-package-maven-plugin in the all/pom.xml; it should resemble the same pattern, as you embed your own core bundle.

A more long-term solution is to remove the dependencies to Guava bit by bit; in many cases this removal should be easily possible, as the JRE adopted much of the functionality Guava provides.

Everything else

With the above 2 steps for ACS AEM Commons and Guava you should be able to address a large portion of the most urgent deprecation. Nevertheless there might be other dependencies which show up.

• Custom code: this should be the easiest solution, as you have full control over it. In many cases the problem is very localized, and should be easy to address. For example I don’t know why anyone would require a direct logback dependency; while there might be valid usecases for it, I think that in many cases this is caused by a simple package import in a java class, which is not used at all. Simply removing that package import could fix this problem, without any functional change required.
• 3rd party dependencies: Much harder to solve, as you cannot change it. As a first step I would check if there are any updates available which fix this behavior. If not, get in contact with the vendor/provider and seek guidance. And let Adobe know if the time window for a fix is clashing with the official API deprecation schedule by Adobe.

In general I believe that much of this work should be straight forward.