Overlays have long been common approach to extend and customize AEM (and CQ before that) functionality.
Standard implementation requires developer to duplicate original overlaid file and place modified version into /apps
Traditionally each AEM version upgrade has required team to carefully inspect current overlays and decide if there's need to make any changes to them. Depending on the amount of overlays this can be very significant undertaking.
With introduction of the AEM as a Cloud Service we no longer know when AEM platform code will change which means that overlays could break at any time without warning.
Idea suggested here improves overlays in 2 different ways
Only actual modifications to the original file are kept in custom implementation ("Don't repeat yourself")
Changes to the original file trigger either warning or build failure depending on the configuration.
Sample configuration to add logging statement to rollout.js could look like this:
Lines after DIFF are output from diff tool when comparing original file and file with intended modifications - same approach as when using patch tool.
Similar configuration format would be required to overlay JCR nodes with option to add, modify and remove properties.
During the deployment all configuration files would be parsed and MD5 hash compared to the contents currently available in /libs structure. If everything is correct source will be modified and overlaid files & nodes placed into /apps into correct place in the repository tree.
Implementation should warn (or fail) if developer attempts to overlay internal or final areas to ensure best practices are followed.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Overlays have long been common approach to extend and customize AEM (and CQ before that) functionality. Standard implementation requires developer to duplicate original overlaid file and place modified version into /apps
Traditionally each AEM version upgrade has required team to carefully inspect current overlays and decide if there's need to make any changes to them. Depending on the amount of overlays this can be very significant undertaking.
With introduction of the AEM as a Cloud Service we no longer know when AEM platform code will change which means that overlays could break at any time without warning.
Idea suggested here improves overlays in 2 different ways
Sample configuration to add logging statement to rollout.js could look like this:
Lines after DIFF are output from diff tool when comparing original file and file with intended modifications - same approach as when using patch tool.
Similar configuration format would be required to overlay JCR nodes with option to add, modify and remove properties.
During the deployment all configuration files would be parsed and MD5 hash compared to the contents currently available in /libs structure. If everything is correct source will be modified and overlaid files & nodes placed into /apps into correct place in the repository tree.
Implementation should warn (or fail) if developer attempts to overlay internal or final areas to ensure best practices are followed.