AEM / CQ Maven Project Structure - Several JCR Node Subcomponents

I found two examples of how to structure Maven artifacts for an AEM project:

<<artifact>> |- <<artifact>>-bundle (OSGi services bundle) |- <<artifact>>-content (Adobe defaults to /apps/<<artifact>>

  1. The cqblueprints script is a multi-module archetype :

<<artifact>> |- <<artifact>>-view (components, templates, clientlibs, design nodes) |- <<artifact>>-config (JCR node configurations) |- <<artifact>>-services (OSGi) |- <<artifact>>-taglib |- <<artifact>>-all |- <<artifact>>-content (/content/<<artifact>> nodes)

I would rather use something like the second; it seems cleaner and will allow developers and developers to avoid conflicts during the development process. For example, the Adobe archetype does not separate user content ( /content/<<artifact>> and /etc/designs/<<artifact>> ) and developer content ( /apps/<<artifact>> and /etc/clientlibs/<<artifact>> ). I can’t find solid information about why Adobe recommends the first style, but maybe something is missing and the Adobe recommended template is the right thing. Can anyone with AEM experience weigh here?

+6
source share
1 answer

This question is a little dangerous, as it encourages opinions instead of facts for which it is not. In any case, I try to refine with my experience.

The Adobe archetype is designed for simple projects and is sufficient in most cases. Do not confuse the suffix of the name -content . It contains the /apps/artifact , so components (including JSP, dialog.xml, etc.) and usually also /etc/designs/artifact . It does not contain content; and I see no reason for this, since the content is not code.

On the other hand, cqblueprint is too fragmented for small projects, but it makes sense for large ones. Although, as stated above, I see no use for the -content part.

I created my own Adobe-based archetype alone with the following parts:

 <<artifact>> |- <<artifact>>-core (OSGi services bundle) |- <<artifact>>-config (environment specific configurations of Adobe and custom OSGi services) |- <<artifact>>-ui (/apps/artifact, /etc/designs/artifact, etc.) 

With experience, you can find another way to structure your CQ / AEM projects that fit your style. Or if you plan to integrate a framework like NEBA or Slice, they probably come with their own project structure.

+2
source

Source: https://habr.com/ru/post/975376/


All Articles