Project structure (Maven archetype)
Purpose: Understand each module the AEM project archetype generates and what belongs where.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Everyone navigates this tree daily |
The modules
phi-academy/
├── core/ Java: models, servlets, services → OSGi bundle
├── ui.apps/ /apps content: components, HTL, dialogs, clientlib defs
├── ui.content/ Sample/seed content (/content, /conf)
├── ui.config/ OSGi configs per run mode
├── ui.frontend/ Webpack/TS frontend build → generated clientlib
├── all/ Aggregate "single package" for deployment
├── dispatcher/ Dispatcher configuration
└── it.tests/ Integration tests (against a running instance)| Question | Answer |
|---|---|
| Where does a new component go? | ui.apps (structure) + core (model) + ui.frontend (styles) |
| Where do OSGi configs go? | ui.config under config.<runmode> folders |
| What actually deploys? | the all package embeds everything: mvn clean install -PautoInstallSinglePackage |
| Where does seed content belong? | ui.content — but production content is authored, never deployed |
Package boundaries worth respecting
coremust not depend on ui.* — Java code addresses content by path/resourceType only.- ui.apps is immutable code (goes to /apps); ui.content is mutable seed (goes to /content, install-once semantics via filter modes).
- Version the
allartefact; it is your deployable release unit (artefacts).
Filevault mapping
ui.apps mirrors the repo: src/main/content/jcr_root/apps/phi-academy/... — folders and .content.xml files map 1:1 to nodes. The filter.xml declares which paths the package owns (and will replace on install).