AEM/CQ Maven Project Structure -- Multiple JCR Node Sub-Modules

Question

I've found two examples for how to structure the Maven artifacts for an AEM project:

1. Adobe's official multimodule-content-package-archetype:

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

2. The cqblueprints 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'd prefer to use something like the second; it seems cleaner and would avoid designers and developers ending up with conflicts during the development process. For example, the Adobe archetype doesn't separate user content (/content/<<artifact>> and /etc/designs/<<artifact>>) and developer content (/apps/<<artifact>> and /etc/clientlibs/<<artifact>>). I can't find any solid information for why Adobe recommends the first style, but perhaps I'm missing something and the Adobe recommended pattern is the right thing to do. Is anybody with AEM experience able to weigh in here?

Answer 1

This question is a bit dangerous as it encourages opinions instead of facts which is not what SO is for. Anyhow I try elaborate with my experience.

The Adobe archetype is meant for simple projects and is sufficient in most cases. Don't get confused by the name suffix -content. It contains the /apps/artifact part so, the components (including JSP, dialog.xml, etc.) and usually also the /etc/designs/artifact. It does not contain content; and I don't see any reason to do so as content is not code.

The cqblueprint is on the other hand overly fragmented for small projects but makes sense for large ones. Though as stated above I don't see the use for the -content part.

I created my own archetype based on the Adobe one 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 may find another way to structure your CQ/AEM projects that suits your style. Or if you plan to integrate a framework like NEBA or Slice they probably come with their own project structure.