{"id":47249,"date":"2017-05-31T14:32:31","date_gmt":"2017-05-31T09:02:31","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=47249"},"modified":"2017-06-01T15:16:20","modified_gmt":"2017-06-01T09:46:20","slug":"how-to-upgrade-existing-code-base-to-latest-aem-version","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/how-to-upgrade-existing-code-base-to-latest-aem-version\/","title":{"rendered":"How to Upgrade Existing Code Base to Latest AEM Version?"},"content":{"rendered":"

Adobe Experience Manager (AEM)<\/a> is an Enterprise Web Content Management System which is used in high impact environments hosting voluminous pages and serving many users.It also involves integration with custom applications and customization of existing AEM features. Because of these complexities, the upgradations of AEM from one version to another one needs to be properly planned and executed. The reason to upgrade a stable system and deal its complexities and issues involved with it can be quite debatable. Nonetheless, one of the last things anyone would like is to have an unsupported site which could run into any issue, plus to be always using a legacy version of AEM whereas the world is going gaga over new features provided by the latest version. So <\/span>upgrading AEM is a basic requirement. Though <\/span>Adobe documentation<\/span><\/a> covers how to upgrade, but making the code compatible with the latest version is not discussed and is often ignored.<\/span><\/p>\n

Recently I was involved in planning and execution of an existing AEM 6.0 code base to AEM 6.2. The critical step was to make the code base ready to be deployed to an AEM 6.2 instance. So through a couple of blogs, I want to focus on how to do the code base upgrade and what challenges are encountered during this process. <\/span><\/p>\n

Here are the\u00a0steps which I followed:<\/span><\/p>\n

\"image6\"<\/p>\n

The approach taken\u00a0in a nutshell is \u2018try to make the code compilable on the upgraded version, test the functionalities and then fix the deprecations.’ Here is a quick explanation of these steps, including the tips which worked for me in executing it.<\/p>\n

STEP 1: Deploy the existing code on new AEM instance<\/span><\/h3>\n

The first step would be to build and deploy the existing code base for older AEM version to new AEM version. For example, if we use MAVEN as a build tool then we can run the command\u00a0<\/span>\u00a0\u2018<\/span>mvn clean install -PautoInstallPackage<\/em>\u2019 on the code base on the latest AEM version instance to deploy the code.\u00a0<\/span>If the build shows errors related to jars, which are incompatible then Step 2 would be required.<\/p>\n

STEP 2: Fix Incompatible Jars & Try to Compile Codebase<\/span><\/h3>\n

We need the dependencies update in pom.xml to make the code compatible with the upgrade. First of all, check for the latest version in <\/span>Adobe\u2019s Maven Repository<\/span><\/a> and validate if the required version is present or not. However, sometimes it would be required to get the version used in AEM installer (primarily because Adobe\u2019s repository doesn\u2019t get updated frequently). <\/span><\/p>\n

So the trick is to retrieve it from AEM\u2019s OSGI console. <\/span>Go to OSGI bundles (<\/span>http:\/\/<host>:<port>\/system\/console\/bundles<\/span><\/i>) and search for the dependency name (say Jackrabbit JCR Commons). Click on the dependency and make a note of the bundle id, i.e. the first column (let\u2019s say it is 102).<\/span><\/p>\n

\"osgi_console\"<\/p>\n

Now go to the crx-repository on the file system <\/span>\u2026.\/crx-quickstart->launchpad->felix->bundle-<id> (bundle-102)<\/span><\/i><\/p>\n

\"bundle_info\"<\/p>\n

If there is a need to validate whether it is the same bundle, then one can check the bundle.info file present under same folder (<\/span>bundle-102<\/span><\/i>).<\/span><\/p>\n

So the bundle.jar can be used and referenced as an external jar dependency.<\/span><\/p>\n

STEP 3: Deploy & Test the build<\/span><\/h3>\n

This\u00a0step\u00a0ensures that the application runs and the functionalities work properly\u00a0<\/span>after successful build and deployment.<\/p>\n

STEP 4: Check for deprecations in code base for both Java & JSP files\u00a0<\/span><\/h3>\n

This step is required to fix the code which is deprecated after the upgrade. Having such a\u00a0coding does not raise any issue as the product upgrade is backwards compatible. However, it is always recommended to remove the deprecations in the code base. To identify these deprecations, I used Eclipse compiler settings to generate errors for any usage of Deprecated API.<\/span><\/p>\n

Go to \u2018<\/span>Preferences -> Java -> Compiler -> Errors\/Warnings -> Deprecated and restricted API section<\/span><\/i>\u2019 and set the level to ERROR (can be warning too, I just felt that identifying errors would be a bit easy to manage). After this change, code base will recompile, and each use of deprecated method or API would show up as an error\/warning in the \u2018Problems\u2019 view.<\/span><\/p>\n

\"deprecated_apis\"<\/p>\n

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 type of problems can be filtered under\u00a0Configure Contents to restrict this list.<\/span><\/p>\n

\"eclipse_problems\"<\/p>\n

STEP 5: Create List of Deprecations & Provide Recommended Solution<\/p>\n

To keep a better track of all the deprecations and fixes, I have created a Master Sheet which consists of deprecations and suggested solutions. It helped me with work distribution among multiple developers working on the same code base.<\/span><\/p>\n

I copied the errors from Eclipse\u2019s Problems console into .xls, sorted them by unique depreciations and provided recommended solutions for each and every deprecation, taking Adobe\u2019s documentation as reference.<\/span><\/p>\n

\"master_upgrade_sheet\"<\/p>\n

I referred to the following AEM documentation links:<\/p>\n

https:\/\/docs.adobe.com\/docs\/en\/aem\/6-2\/develop\/ref\/javadoc\/deprecated-list.html#package<\/span><\/a><\/p>\n

https:\/\/docs.adobe.com\/docs\/en\/aem\/6-2\/develop\/ref\/diff-previous\/changes.html<\/span><\/a><\/p>\n

https:\/\/docs.adobe.com\/docs\/en\/aem\/6-2\/release-notes\/deprecated-removed-features.html<\/span><\/a><\/p>\n

Respective links are available for other AEM versions too.<\/p>\n

STEP 6: Fix the Deprecations in Codebase<\/span><\/h3>\n

The approach followed was to fix the unique deprecations first. Usually, if it works in one functionality, then it should work in other use cases too. Mostly the repairs recommended by Adobe work but there can be scenarios where they fail. So either one needs to figure out a workaround or keep the deprecated code in place, until the identification of a new recommendation.<\/span><\/p>\n

STEP 7: Deploy & Test the Build<\/span><\/h3>\n

This step is simply to ensure that after successful build and deployment, the application is running and the functionalities are working fine. As stated above, it is highly possible that the recommended fixes by Adobe wouldn\u2019t work for all the use cases implemented in any custom application. So a thorough testing of depreciation fixes is required.<\/span><\/p>\n

What’s missing?\u00a0<\/span><\/h3>\n

This blog doesn\u2019t cover another critical step of how to make the code compatible with the front <\/span>end, where let\u2019s say, AEM\u2019s out of the box (OOTB) Javascript(js)\u00a0are overlaid and customized. In my project, we did not do this in the first upgrade release, primarily because of less time in hand. If time isn\u2019t a constraint, then a quick comparison of overlaid js\u00a0with latest AEM\u2019s OOTB js should also be made.<\/span><\/p>\n

In my next blog, I would cover the most common deprecations fixed in an upgrade from AEM 6.0 to 6.2, along with the use cases where the recommended depreciation fixes did not work. \u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Adobe Experience Manager (AEM) is an Enterprise Web Content Management System which is used in high impact environments hosting voluminous pages and serving many users.It also involves integration with custom applications and customization of existing AEM features. Because of these complexities, the upgradations of AEM from one version to another one needs to be properly […]<\/p>\n","protected":false},"author":993,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":5},"categories":[1],"tags":[4847,1813,4051],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/47249"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/993"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=47249"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/47249\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=47249"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=47249"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=47249"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}