Complete Guide to Upgrade Existing Code Base to Latest AEM (Adobe Experience Manager) Versions
To establish a smooth transformation, you need to implement AEM practices and associate with the right service provider or partner agency to avoid roadblocks, overpriced errors, and delays.
Below are the suggested steps to be followed:
- Set up existing code on a new AEM instance
Always the first step should be to set up a new code of the AEM version to install in the place of the older AEM version code. For example, if you use MAVEN as a build tool, then the ‘mvn clean install- PautoInstallPackage’ command can be run on the base code of the latest AEM version instance to deploy the code.
If the build shows errors related to jars, which are incompatible then Step 2 would be required.
2. Fix unsuitable JAR (Java ARchive) and then compile the code base
To make the code compatible with the upgrade, update the dependencies in pom.xml. The latest version of Adobe’s Maven Repository should be analyzed and validated to check its reliability and relevancy in the framework.
However, due to the lack of regular renovation of Adobe’s repository, there will be times when you will need to get the version used in the AEM installer. However, you can get it from AEM’s OSGI console. You can search for the dependency name from OSGI bundles (../system/console)
For example, just click on the dependency, and note down the bundle id, i.e., the first column. (check the below image)
Check the crx-repository on the file system …./crx-quickstart->launchpad->felix->bundle-<id> (bundle-102)
You can check under bundle.info file present under the same folder (bundle-102) in case validation is required.
bundle.jar will become a backing and can be used as an external JAR dependency.
3. Install and test the build
Post-deployment, run the application to test the functionalities and check the build.
4. Check for gaps in the code base for both Java & JSP files
The deprecated code must be fixed post the upgrade to ensure that the upgrade is backwards compatible. The deprecations must be removed at the code base.
To recognize these deprecations, you can use Eclipse compiler settings to bring out errors from any usage of deprecated API.
Go in this sequence — ‘Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API section’ and set the level to ERROR.
Once this change is done, the code base gets recompiled, and each use of deprecated method or API appears as an error/warning in the ‘Problems’ view.
In case you want to copy the full error list from Eclipse, From the ‘Problems’ view, click on the view menu and change the number of visible items under ‘preferences.
Now, if there is a requirement to copy the entire error list from Eclipse, go to Problems view, click on the View Menu (the triangle icon) and change the number of visible items under Preferences. (by default, it is 100). Even ‘types of problems’ can be filtered under Configure Contents to restrict this list.
5. Create a list of deprecations in the code base and decide on the solutions
You should create a Master sheet that has details of deprecations and solutions. Other developers working on the same code base also can benefit from this information.
6. Fix the issues
The first step is to fix the exclusive depreciations. Generally, it is seen that if it performs well then it works in other use cases too.
In the case of failures, the code should be error-free, or the deprecated code must be there as is until a solution is found.
7. Make the code compatible with the front end
It is highly suggested that the code should be compatible with the front end. AEM’s OOTB (Out Of The Box) JS (JavaScript) are overlaid and customized. Ensure that there is room for a quick comparison of overlaid JS with the latest AEM’s OOTB JS.
8. Install and test build
Timely testing at all stages is highly recommended for the framework to function properly.
**AEM documentation links were referred while writing this blog.
