Move /etc/acs-commons to /content/acs-commons

[kwin]

Expected Behavior

Since AEM 6.4 the migration of /etc to other areas of the repository has started. That means that in the end no code/content should end up below /etc. Further information in https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/repository-restructuring.html#

Actual Behavior

ACS Commons still places content below /etc/acs-commons. Also clientlibraries are still placed below /etc/clientlibs/acs-commons/.

In my opinion the support for Classic UI should be deprecated and the actual pages below /etc/acs-commons should be moved to /content/acs-commons. That would mean in the classic UI the pages are exposed below /siteadmin instead of /miscadmin. For the Touch UI nothing will change, as already now the navigation is contributed by https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/master/content/src/main/content/jcr_root/apps/cq/core/content/nav/tools/acs-commons (which hides the location of the actual underlying pages). At the same time the client libs should be moved from /etc/clientlibs/acs-commons to /apps/acs-commons/clientlibs (and made accessible via the proxy option).

[justinedelson]

I think for the non-clientlib cases, /conf would make more sense.

This should really be decomposed into separate issues. #986 should cover the Generic Lists case, but there are obviously others which need to be dealt with (packagers, notifications, reports, etc.).

[kwin]

/conf is IMHO not exposed at all in the Classic UI, so those pages would be invisible in Classic UI. If you don't want to place them below /content I would rather go for /apps/acs-commons/content because ~~all~~ most of those pages are in fact not editable (so they are comparable to e.g. /libs/granite/operations/content/systemoverview.html`). WDYT?

[kwin]

I think as first step we could migrate all those pages which are marked in https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/content/src/main/content/META-INF/vault/filter.xml#L33 with an include pattern ending with (.*)? to /apps/acs-commons/content. For the other ones we need to think a bit more where to place them.

[justinedelson]

Right, I was thinking of the authorable cases that I mentioned. For standalone tools, /apps makes more sense. It'll even make sense for the admin tools which allow editing of the authorable things, but the things themselves belong under /conf

[royteeuwen]

Maybe this might be an unpopular thing to say, but seeing as I thought that acs-commons always supported 2 versions, so that would mean 6.4 and 6.5 in which classic ui is already deprecated / removed. So maybe for the next release we don't have to take account of classic ui anymore? Or when do you see this happening.

[stale[bot]]

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.

[kwin]

This is now tracked in #1975

[badvision]

Maybe this might be an unpopular thing to say, but seeing as I thought that acs-commons always supported 2 versions, so that would mean 6.4 and 6.5 in which classic ui is already deprecated / removed. So maybe for the next release we don't have to take account of classic ui anymore? Or when do you see this happening.

Unpopular or no, but Classic UI was deprecated since 6.2 so you should absolutely expect anything related to Classic UI to disappear in the near future.

[badvision]

One thing to keep in mind is that the legacy configuration manager still presumes /etc/conf; and there's no immediate plans for any change to that product behavior. I encountered this recently when looking at possible modernization improvements on-deploy scripts. I'm not sure what our options are for configuration-related unless we cook up our own replacement configuration API that leverages the /conf context-aware stuff somehow. Seems like a costco-sized can of worms though.

[joerghoh]

Also one thing to consider: We can finish the cleanup of /etc only when we drop support for AEM 6.3. Because until then we need to have changes to /etc, even if it's only permissions for service users.

[joerghoh]

For sure it's a major change in the content structure, but it does really break any (formal or informal) contracts? If not, I would like move it to the 5.1.0 milestone.

[kwin]

Some properties below /etc is configuration settings. So the change to /content requires a content migration. Therefore I consider this a major change which should be done with 5.0.

[kwin]

Related to #2354

[shajiahmed]

we are restructuring content as per adobe instructions When I create the list in AEM 6.5 with ACS commons version 5.0.4 I still see acs-commons still stores list in /etc How do we change this settings when moving to /apps? Are there any documentations on acs-commons restructuring.