Day 12 of 40
WKND: Project Setup
Generating the WKND project and building it for the first time
By the end of today you should be able to
- Generate the WKND project and build it against a local AEM instance
- Explain what each Maven profile does and when to reach for it
- Diagnose the three failures that account for most first builds
- Confirm the deployment landed by inspecting the repository and bundle state
What you are building
WKND is Adobe's reference site — a fictional travel brand — and the tutorial builds it with the archetype, chapter by chapter. Working through it gives you a complete, realistic project rather than a toy. Each chapter has its own Git branch, so you can jump in at any point or compare your work against the reference implementation.
The chapters map onto the next ten days: project setup, component basics, pages and templates, client-side libraries, style system, a custom component, and unit testing.
Generating and building
mvn -B org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate \
-D archetypeGroupId=com.adobe.aem \
-D archetypeArtifactId=aem-project-archetype \
-D archetypeVersion=XX \
-D appTitle="WKND Sites Project" \
-D appId="wknd" \
-D groupId="com.adobe.aem.guides" \
-D aemVersion="cloud"
cd wknd
mvn clean install -PautoInstallPackage
Note the ordering of what happens: Maven compiles core, runs its unit tests, builds
ui.frontend with npm, copies the resulting clientlib into ui.apps, packages
every content module, assembles all, then uploads and installs that single package to
the instance on 4502.
The profiles worth knowing
-PautoInstallPackage— build everything, installallto author (4502).-PautoInstallPackagePublish— same, but to publish (4503).-PautoInstallBundle -pl core— compile and hot-deploy only the OSGi bundle. Much faster, and the one you will use most while writing Java.-PautoInstallSinglePackage— install a single module's package rather than the wholeall.- Add
-DskipTestswhen you are iterating and know the tests pass. Do not make it a habit.
A full -PautoInstallPackage can take a couple of minutes. -PautoInstallBundle -pl core takes seconds. Learning which one your change actually needs is one of the biggest quality-of-life wins in AEM development.
When the first build fails
Three causes account for nearly all of them:
- Wrong Java version. Check
java -versionandmvn -versionagree and match what the archetype expects. Multiple JDKs on one machine is the usual culprit. - Maven cannot resolve Adobe artefacts. The archetype pulls from Adobe's public repository. A corporate proxy or a
settings.xmlwith a restrictive mirror will break this with a confusing "could not resolve dependencies" message. - AEM is not running, or is on a different port. The install step POSTs to
localhost:4502using the credentials in the profile. A stopped instance or a changed admin password fails here — and the failure comes at the very end, after a long build.
Confirming it worked
Do not trust "BUILD SUCCESS" alone. Check three things:
- The repository:
/apps/wkndexists in CRXDE Lite, withcomponentsandclientlibsbeneath it. - The bundle: at
/system/console/bundles, search for your bundle symbolic name (something likecom.adobe.aem.guides.wknd.core) and confirm it is Active. A bundle stuck at Installed means the deploy technically succeeded but your Java is not running. - The site:
/sites.html/content/wkndshows the generated site, and you can open a page in the editor.
This is the confusing case. Maven reports success because the package installed; the bundle then failed to resolve inside AEM. Always check the bundle state after a deploy that "worked" but changed nothing.
Generate, build, install, then verify in three places: repository, bundle state, rendered site. Learn -PautoInstallBundle early — it will save you hours.
Watch
Adobe's own videos for this topic. They load only when you press play.
Read on Experience League
The primary sources these notes are drawn from.
Your notes
Saved automatically to this browser.
Check yourself
9 questions on today's material. 80% to pass.