Why Adobe moved client libs from etc to apps? | Community
Skip to main content
sathishreddy
sathishreddy
Level 2
July 20, 2020
Solved

Why Adobe moved client libs from etc to apps?

  • July 20, 2020
  • 2 replies
  • 1761 views

Hi all,

 

Why adobe moved client libs from etc to apps?

 

And we are not able to call client libs from apps directly, again we calling via etc/design. Why they defined like that? 

 

Thanks,

Satish

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by aemmarc2

Long story short : Today in 2020 AEM is available as SaaS offering. To transform AEM from a monolithic Java application to something that runs inside orchestration containers required a series of repository restructurings that started in AEM 6.4 and furthered in 6.5.  Within this containered-AEM-world there is a concept of immutable and mutable nodes. Eg /etc is considered immutable, thus required forcing customers to migrate their stuff out of these paths to /apps (mutable).

 

Hope that helps your understanding. 

2 replies

Nupur_Jain
Adobe Employee
Nupur_JainAdobe Employee
Adobe Employee
July 20, 2020

Hi @sathishreddy 

 

The reasons for allowing flexibility to allow clientlibs from /etc to /apps is given in the adobe documentation itself. Refer https://docs.adobe.com/content/help/en/experience-manager-65/developing/introduction/clientlibs.html#locating-a-client-library-folder-and-using-the-proxy-client-libraries-servlet.

 

  • This is to locate the client libraries near the other scripts, which are generally found below /apps and /libs
  • In order to better isolate code from content and configuration, it is recommended to locate client libraries under /apps and expose them via /etc.clientlibs by leveraging the allowProxy property
  • Before when we used to declare clientlibs in /etc. We had to allow /etc paths access to end user as well as if we wanted to keep js/css under the component. we had to either embed our original clientlibs in site clientlibs in /etc or directly define js/css in /etc clientlibs. This proxy clientlibs does not require this two way step process. we can now easily keep component specific js/css files near component and make it available to end users using allowProxy property.

 

Hope it helps!

Thanks!

Nupur

    A
    Adobe Employee
    aemmarc2Adobe EmployeeAccepted solution
    Adobe Employee
    July 20, 2020

    Long story short : Today in 2020 AEM is available as SaaS offering. To transform AEM from a monolithic Java application to something that runs inside orchestration containers required a series of repository restructurings that started in AEM 6.4 and furthered in 6.5.  Within this containered-AEM-world there is a concept of immutable and mutable nodes. Eg /etc is considered immutable, thus required forcing customers to migrate their stuff out of these paths to /apps (mutable).

     

    Hope that helps your understanding. 

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      July 20, 2020
      ah, not really 🙂 /apps is immutable (no changes during runtime), and /etc is deprecated, because there was no policy at all, so both mutable and immutable data was dropped there. So from a product point of view /etc will go away over time..
        Terms & ConditionsAccessibility statement

        Loading footer...