Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

Why Adobe moved client libs from etc to apps?

sathishreddy
Level 2
Level 2

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

1 Accepted Solution
aemmarc
Correct answer by
Employee
Employee

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. 

View solution in original post

4 Replies
Nupur_Jain
Community Advisor
Community Advisor

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...

 

  • 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

aemmarc
Correct answer by
Employee
Employee

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. 

View solution in original post

Jörg_Hoh
Employee
Employee
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..
aemmarc
Employee
Employee
Thanks for expanding on my understanding Jörg.