AEM Multi-Project Example

Description

This project could be used to start developing long-term project based on AEM.

To start developing application/library based on AEM it is recommended to use Gradle AEM Single instead.

Documentation for AEM plugin is available in project Gradle AEM Plugin.

Screenshot

Table of Contents

• Features
• Quickstart
• Environment
• Structure
• Building
• Tips & tricks
• Running tests
• Attaching debugger
• Extending build

Features

Main motivation of this project is to automate all aspects of AEM development and make it a breeze.

---

Archetyping:

• Generating project from archetype using Gradle Fork Plugin,
• Generating user-specific build properties using friendly GUI

Environment:

• Automatic native local AEM instance(s) setup,
• Automatic HTTPD server with AEM dispatcher setup (based on Docker),
• Hosts file amendment - aem.environment.hosts,
• Health checking - aem.environment.healthChecks

Back-end:

• Interoperable Java and Kotlin code examples.
• Examples for:
  • Embedding JAR file into OSGI bundle - bundlePrivateEmbed
  • Including additional OSGi bundle into CRX package - packageCompose.fromJar

Front-end:

• Setup of popular UI build toolkit: NodeJS, Yarn and Webpack for advanced assets bundling (modular JS, ECMAScript6 transpilation, SCSS compilation with PostCSS, code style checks etc).
• Integrated SCSS compilation on AEM side using AEM Sass Compiler.

Testing:

• Unit tests using popular AEM testing toolkit - wcm.io Testing.
• Integration tests using Karate Framework and JSoup.
• Functional tests using Cypress
• Performance tests using Gradle Lighthouse Plugin

Maintenance:

• Automatic AEM migration scripts execution using AEM Easy Content Upgrade,
• Automatic AEM access control configuration applying using Access Control Tool,
• Interactive incident monitoring / logs monitoring with filtering.

Quickstart

1. Fork project using command:

   git clone https://github.com/Cognifide/gradle-aem-multi.git && cd gradle-aem-multi && sh gradlew fork

   and specify properties:

   

   and wait until project is forked then enter configured target directory.

2. Setup user specific project configuration using command:

   sh gradlew props

   and specify properties:

   

3. Setup local AEM instances with dependencies and AEM dispatcher (see prerequisites) then build application using command:

   sh aem/hosts
   sh gradlew setup

   and wait till complete AEM environment will be ready to use.

4. Develop continuously application using command:

   sh gradlew

   which is an alias for:

   sh gradlew develop

   or to just deploy AEM application (without running anything else):

   sh gradlew :aem:assembly:full:packageDeploy

Prerequisites

Tested on:

• Java 1.8
• Gradle 5.4.1
• Adobe AEM 6.5
• Docker 2.0.0.3

Structure

Project is divided into subpackages (designed with reinstallabilty on production environments in mind):

• aem/assembly/full - non-reinstallable complete all-in-one package with application and contents (combination of subpackages: all). Useful to deploy all code by installing single package in a project stage when application is not live.

• aem/assembly/app - reinstallable assembly package that contains only application code, not content (combination of subpackages: common, sites). Useful to deploy application code only in a project stage when application is live and content should remain untouched on production server.

• aem/common - OSGi bundle with integrations of libraries needed by other bundles and global AEM extensions (dialogs, form controls etc). Only code unrelated to any site / AEM platform wide.

• aem/sites - AEM sites module extension consisting of site specific code like: OSGi bundle with business logic, AEM components, templates, design.

• aem/site.demo - consists of extra AEM pages that presents features of application (useful for testing). Helps application testers and developers in QA/UAT application feature tests.

• aem/site.live - contains minimal set of pages needed initially to rollout new site(s) using installed application. Helps content authors to start working with application.

Environment

Project is configured to have local environment which consists of:

• native AEM instances running on local file system,
• virtualized Apache HTTP Server with AEM Dispatcher module running on Docker (official httpd image).

Assumptions:

• AEM author available at http://localhost:4502
• AEM publish available at http://localhost:4503
• Apache web server with Virtual hosts configured for domains:
  • http://example.com -> which maps to /content/example/live content root on publish
  • http://demo.example.com -> which maps to /content/example/demo content root on publish
  • http://author.example.com -> which is proxy to the author instance

Building

1. Use command gradlew so that Gradle in version according to project will be downloaded automatically.
2. Deploy application:
   • Full assembly and run all tests
     • sh gradlew <=> sh gradlew :develop
   • Only assembly packages:
     • sh gradlew :aem:assembly:full:packageDeploy
     • sh gradlew :aem:assembly:app:packageDeploy
   • Only single package:
     • sh gradlew :aem:sites:packageDeploy,
     • sh gradlew :aem:common:packageDeploy,
     • sh gradlew :aem:site.demo:packageDeploy.
     • sh gradlew :aem:site.live:packageDeploy,

Tooling

1. Monitoring errors in logs: sh gradlew instanceTail
2. Synchronizing JCR content from AEM to local file system:
   • sh gradlew :aem:site.demo:sync
   • sh gradlew :aem:site.live:sync
3. Interactively updating HTTPD Virtual-Host & AEM Dispatcher configuration: sh gradlew environmentDev
4. Copying JCR content between AEM instances: sh gradlew :aem:sites:demo:rcp -Prcp.source=http://user:[email protected]:4502 -Prcp.target=local-author -Prcp.paths=[/content/example,/content/dam/example]

Tips & tricks

• To run some task only for subproject, use project path as a prefix, for instance: sh gradlew :aem:sites:packageDeploy.
• According to recommendations, Gradle daemon should be:
  • enabled on development environments,
  • disabled on continuous integration environments.
• To see more descriptive errors or want to skip some tasks, see command line documentation.

Running tests

IntelliJ

Certain unit tests may depend on the results of running gradle tasks. One such example is the testing of OSGi Services using OSGi Mocks where in order to run a test, the SCR metadata must be available for a class. Running a test like this in IntelliJ results in errors because the IDE is not aware of the Bundle plugin.

This can be worked around by configuring IntelliJ to delegate test execution to Gradle. In order to set this up, go to Settings > Build, Execution, Deployment > Gradle > Runner and set your IDE to delegate IDE build/run actions to Gradle. Alternatively, you can use a dropdown menu to use a specific runner or to decide on a test-by-test basis.

Attaching debugger

1. Execute build with options -Dorg.gradle.debug=true --no-daemon, it will suspend,
2. Attach debugger on port 5005,
3. Suspension will be released and build should stop at breakpoint.

Extending build

For defining new tasks directly in build see:

• Build Script Basics
• More about Tasks

The easiest way to implement custom plugins and use them in project is a technique related with buildSrc/ directory. For more details please read documentation.