Show Menu
TOPICS×

Chapter 1 - Project Setup

Covers the creation of a Maven Multi Module Project to manage the code and configurations for an AEM Site.

Prerequisites

This is Part 1 of the multi-part tutorial. An overview can be found here .
A local development environment is necessary to complete this tutorial. Screenshots and video are captured from a Mac OS environment but the commands and code used should be independent of the local operating system, unless otherwise noted.
The following is required:
  1. Java 1.8 or Java 11 (AEM 6.5+ only)
  2. Apache Maven (3.3.9 or newer)
  3. Adobe Experience Manager
  4. Eclipse or other IDE

Objective

  1. Learn how to generate a new AEM project using a Maven archetype.
  2. Understand the different modules generated by the AEM Project Archetype and how they work together.
  3. Understand how AEM Core Components are included in an AEM Project.

Create Project with Maven AEM Project Archetype 18

There are a couple options for creating a Maven Multi-module project for AEM. This tutorial will leverage the Maven AEM Project Archetype 18 .
For the purposes of following this tutorial we will use version 18 of the archetype. It is always a best practice to use the latest version of the archetype to generate a new project.
  1. A best practice is to add an adobe-public profile to your Maven settings.xml file in order to automatically add repo.adobe.com to the maven build process.
  2. Create a file named settings.xml at ${user.home}/.m2/settings.xml if it doesn't exist already.
  3. Add the adobe-public profile to the settings.xml file based on the instructions here .
    A sample settings.xml is listed below or can be directly downloaded . Note, the naming convention of settings.xml is important.
    <settings xmlns="https://maven.apache.org/SETTINGS/1.0.0"
      xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0
                          https://maven.apache.org/xsd/settings-1.0.0.xsd">
    <profiles>
    <!-- ====================================================== -->
    <!-- P U B L I C P R O F I L E -->
    <!-- ====================================================== -->
    <profile>
        <id>adobe-public</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <releaseRepository-Id>adobe-public-releases</releaseRepository-Id>
            <releaseRepository-Name>Adobe Public
                Releases</releaseRepository-Name>
            <releaseRepository-URL>https://repo.adobe.com/nexus/content/groups/public</releaseRepository-URL>
        </properties>
        <repositories>
            <repository>
                <id>adobe-public-releases</id>
                <name>Adobe Basel Public Repository</name>
                <url>https://repo.adobe.com/nexus/content/groups/public</url>
                <releases>
                    <enabled>true</enabled>
                    <updatePolicy>never</updatePolicy>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </repository>
        </repositories>
        <pluginRepositories>
            <pluginRepository>
                <id>adobe-public-releases</id>
                <name>Adobe Basel Public Repository</name>
                <url>https://repo.adobe.com/nexus/content/groups/public</url>
                <releases>
                    <enabled>true</enabled>
                    <updatePolicy>never</updatePolicy>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </pluginRepository>
        </pluginRepositories>
     </profile>
    </profiles>
     <activeProfiles>
         <activeProfile>adobe-public</activeProfile>
     </activeProfiles>
    </settings>
    
    
  4. The next series of steps will take place using a UNIX based command line terminal, but should be similar if using a Windows terminal.
    Open up a command line terminal and verify that Maven has been installed and added to the command line path:
    $ mvn -version
    ...
    Apache Maven 3.3.9
    Maven home: /Library/apache-maven-3.3.9
    Java version: 1.8.+, vendor: Oracle Corporation
    Java home: /Library/Java/JavaVirtualMachines/jdk1.8.+.jdk/Contents/Home/jre
    
    
  5. Navigate to a directory in which you want to generate the AEM project. This can be any directory in which you want to maintain your project's source code. For example a directory named src :
    cd ~/
    mkdir src
    cd ~/src
    
    
  6. Paste the following into the command line to initiate the creation of a new project:
     mvn archetype:generate \
      -DarchetypeGroupId=com.adobe.granite.archetypes \
      -DarchetypeArtifactId=aem-project-archetype \
      -DarchetypeVersion=18
    
    
    
    It is also possible to create the Maven AEM project using the AEM Developer Tools plugin for Eclipse .
    If you receive an error like the following: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate (default-cli) on project standalone-pom: The desired archetype does not exist . It is an indication that the Adobe repo is not properly referenced in your ~/.m2/settings.xml file. Please revisit the earlier steps and verify that the settings.xml file references the Adobe repo. An alternative is to explicitly reference the granite archetype when generating the archetype:
     mvn archetype:generate \
     -Padobe-public \
     -DarchetypeGroupId=com.adobe.granite.archetypes \
     -DarchetypeArtifactId=aem-project-archetype \
     -DarchetypeVersion=18
    
    
    
  7. The AEM project archetype will ask a series of questions to set up the project. The following table lists the values used for this tutorial:
    Description
    Property
    Value
    Maven group id
    groupId
    com.adobe.aem.guides
    /apps folder name
    appsFolderName
    wknd
    Maven artifact id
    artifactId
    aem-guides-wknd
    Starting version of project
    version
    0.0.1-SNAPSHOT
    Java source package
    package
    com.adobe.aem.guides.wknd
    Maven project name
    artifactName
    WKND Sites Project
    AEM component group name
    componentGroupName
    WKND.Content
    /conf folder name
    confFolderName
    wknd
    /content folder name
    contentFolderName
    wknd
    Prefix used in generated CSS
    cssId
    wknd
    Content Package group name
    packageGroup
    wknd
    AEM site name
    siteName
    WKND Site
  8. The following folder and file structure will be generated by the Maven archetype:
    ~/src/
        |--- aem-guides-wknd/
            |--- core/
            |--- it.launcher/
            |--- it.tests/
            |--- pom.xml
            |--- README.md
            |--- ui.apps/
            |--- ui.content/
    
    
    The files and folders generated will be examined in more detail later in the tutorial.
  9. Navigate into the aem-guides-wknd directory and run the following maven command to build and deploy the project
    $ cd aem-guides-wknd
    $ mvn -PautoInstallPackage clean install
    ...
    [INFO] ------------------------------------------------------------------------
    [INFO] Reactor Summary:
    [INFO]
    [INFO] aem-guides-wknd .................................... SUCCESS [  0.369 s]
    [INFO] WKND Sites Project - Core .......................... SUCCESS [  3.836 s]
    [INFO] WKND Sites Project - UI apps ....................... SUCCESS [  3.172 s]
    [INFO] WKND Sites Project - UI content .................... SUCCESS [  0.554 s]
    [INFO] WKND Sites Project - Integration Tests Bundles ..... SUCCESS [  0.896 s]
    [INFO] WKND Sites Project - Integration Tests Launcher .... SUCCESS [  2.574 s]
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 12.530 s
    [INFO] Finished at: 2018-04-04T18:17:45-04:00
    [INFO] Final Memory: 57M/600M
    [INFO] ------------------------------------------------------------------------
    
    
    
    the Maven profile autoInstallPackage is the most common profile used to deploy an AEM project. The archetype generates a POM file that will deploy to an AEM instance running locally on port 4502 and with the credentials of admin:admin .
    mvn -PautoInstallPackage clean install
    
    
    
  10. View Packages on AEM
    Navigate to Package Manager on your local AEM instance: http://localhost:4502/crx/packmgr/index.jsp . You should see two packages for aem-guides-wknd.ui.apps and aem-guides-wknd.ui.content .
    Notice that 2 or more packages related to core components were also installed. We will inspect this further below.
  11. Navigate from the AEM Start screen to Sites . The WKND Site will be one of the sites. It will include two content pages, one for English and one for French.
  12. Open the English page by selecting the page and clicking the Edit button in the menu bar:
  13. Some content is already created and several components are available to be added to a page. Experiment with these components to get an idea of the functionality. How this page and components are configured will be explored in detail later in the tutorial.

Inspecting the Project Structure

There are six areas to the project that was generated:
  • Parent POM - deploys maven modules and manages dependency versions
  • core - Java bundle containing all core functionality like OSGi services, listeners or schedulers, as well as component-related Java code such as servlets or request filters.
  • ui.apps - contains the /apps parts of the project, ie JS&CSS clientlibs, components, runmode specific configs as well as Hobbes-tests
  • ui.content - contains structural content and configurations (/content, /conf)
  • ui.tests - Java bundle containing JUnit tests that are executed server-side. This bundle is not to be deployed onto production.
  • ui.launcher - contains glue code that deploys the ui.tests bundle (and dependent bundles) to the server and triggers the remote JUnit execution

Parent POM

In the pom.xml at the root of the project ( <src-directory>/aem-guides-wknd/pom.xml ), several global properties are defined:
<properties>
        <aem.host>localhost</aem.host>
        <aem.port>4502</aem.port>
        <aem.publish.host>localhost</aem.publish.host>
        <aem.publish.port>4503</aem.publish.port>
        <sling.user>admin</sling.user>
        <sling.password>admin</sling.password>
        <vault.user>admin</vault.user>
        <vault.password>admin</vault.password>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>


These properties are set up to deploy to a local AEM instance, as this is the most common build that developers will do. Notice there are properties to deploy to an Author Instance as well as a Publish instance. This is also where the basic-auth credentials are set to authenticate with the AEM instance. The default admin:admin credentials are used.
These properties are setup so that they can be overridden when deploying to higher level environments. In this way the POM files do not have to change, but variables like aem.host and sling.password can be overridden via command line arguments:
 mvn -PautoInstallPackage clean install -Daem.host=production.hostname -Dsling.password=productionpasswd


The Parent POM will build five sub-modules: core , ui.apps , ui.content , ui.tests , it.launcher . These modules are defined at the bottom of the file. More modules can always be added as a project evolves.
<modules>
        <module>core</module>
        <module>ui.apps</module>
        <module>ui.content</module>
        <module>it.tests</module>
        <module>it.launcher</module>
</modules>


The Parent POM includes a DependencyManagement section that lists all of the dependencies and versions of APIs that are going to be used in the project. Versions should be managed in the Parent POM and sub-modules like Core and UI.apps should not include any version information.
One of the key dependencies to inspect is the AEM uber-jar. This will include all of the AEM APIs with just a single dependency entry for the version of AEM. More information about the uber-jar can be found here .
 <dependencyManagement>
        ...
         <dependency>
                <groupId>com.adobe.aem</groupId>
                <artifactId>uber-jar</artifactId>
                <version>6.5.0</version>
                <scope>provided</scope>
                <classifier>apis</classifier>
            </dependency>
            ...
</dependencyManagement>


As a best practice you should update the uber-jar version to match the target version of AEM. i.e, if you plan to deploy to AEM 6.4 you should update the version of the uber-jar to 6.4.0.

Core Module

The Core maven module ( <src-directory>/aem-guides-wknd/core ) will include all the Java code needed for the implementation. The module will package all of the Java code and deploy to the AEM instance as an OSGi Bundle.
The Maven Bundle Plugin defined in the aem-guides-wknd/core/pom.xml is responsible for compiling the Java code into an OSGi bundle that can be recognized by AEM's OSGi container. Notice that this is where the location of Sling Models are defined. This will be leveraged in later parts of the tutorial.
//core/pom.xml

<plugin>
    <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
            <instructions>
            <!-- Import any version of javax.inject, to allow running on multiple versions of AEM -->
            <Import-Package>javax.inject;version=0.0.0,*</Import-Package>
                    <Sling-Model-Packages>
                        com.adobe.aem.guides.wknd.core
                    </Sling-Model-Packages>
            </instructions>
    </configuration>
</plugin>


The Maven Sling Plugin allows the Core Bundle to be deployed to AEM directly leveraging the autoInstallBundle profile (defined in the Parent Pom.xml).
It is rare that the Core Bundle is deployed independently of the ui.apps module in upper level environments. Deploying the Core Bundle directly is useful during local development/testing.
//core/pom.xml

<plugin>
    <groupId>org.apache.sling</groupId>
    <artifactId>maven-sling-plugin</artifactId>
</plugin>


  1. Try building the Core module independently from the rest of the project with the following commands from the terminal:
    $ cd aem-guides-wknd/core/
    $ mvn -PautoInstallBundle clean install
    ...
    [INFO] Installing Bundle com.adobe.aem.guides.aem-guides-wknd.core(/src/aem-guides-wknd/core/target/aem-guides-wknd.core-0.0.1-SNAPSHOT.jar) to http://localhost:4502/system/console via WebConsole
    [INFO] Bundle installed
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 4.304 s
    [INFO] Finished at: 2018-04-05T12:10:59-04:00
    [INFO] Final Memory: 29M/469M
    [INFO] ------------------------------------------------------------------------
    
    
    
  2. Navigate to http://localhost:4502/system/console/bundles you should be able to see the bundle installed and active.
    The OSGi bundle is a jar that gets deployed to the AEM repository as an embedded part of the ui.apps module.
  3. You can see the 'physical' location of the jar in CRXDE-Lite :

UI.apps Module

UI.apps maven module will include all of the rendering code needed for the site beneath /apps. This includes CSS/JS that will be stored in an AEM format called clientlibs . This also includes HTL scripts for rendering dynamic HTML. You can think of the ui.apps module as a map to the structure in the JCR but in a format that can be stored on a file system and committed to source control.
The Apache Jackrabbit FileVault Package plugin is used to compile the contents of the ui.apps module into an AEM package that can be deployed to AEM. The global configurations for the plugin are defined at the Parent pom.xml.
  1. Open the pom.xml beneath <src>/aem-guides-wknd/pom.xml :
    Inspecting the plugin definition you can see a configuration for filterSource . The filterSource points to the location of the filter.xml file that is used to define the jcr paths that are included in the package. The filterSource points to the location of the filter.xml file that is used to define the jcr paths that are included in the package. Beneath the FileVault Package plugin is the definition of the Content Package Plugin which is used to then push the package into AEM. Note that variables for aem.host, aem.port, vault.user, and vault.password are used that correspond to the global properties.
    // pom.xml
    
    <!-- Jackrabbit FileVault Package Plugin -->
    <plugin>
        <groupId>org.apache.jackrabbit</groupId>
        <artifactId>filevault-package-maven-plugin</artifactId>
        <version>1.0.1</version>
        <configuration>
            <filterSource>src/main/content/META-INF/vault/filter.xml</filterSource>
        </configuration>
    </plugin>
    <!-- Content Package Plugin -->
    <plugin>
        <groupId>com.day.jcr.vault</groupId>
        <artifactId>content-package-maven-plugin</artifactId>
        <version>1.0.2</version>
        <configuration>
            <targetURL>https://${aem.host}:${aem.port}/crx/packmgr/service.jsp</targetURL>
            <failOnError>true</failOnError>
            <userId>${vault.user}</userId>
            <password>${vault.password}</password>
        </configuration>
    </plugin>
    
    
    
  2. Open the file ui.apps/pom.xml :
    Looking at the ui.apps/pom.xml you can see the filevault-package-maven-plugin . The embedded tags includes the compiled core bundle as part of the ui.apps package and where it will be installed.
    //ui.apps/pom.xml
    
    <!-- ====================================================================== -->
    <!-- V A U L T   P A C K A G E   P L U G I N                                -->
    <!-- ====================================================================== -->
    <plugin>
        <groupId>org.apache.jackrabbit</groupId>
        <artifactId>filevault-package-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
        <embeddeds>
            <embedded>
                <groupId>com.adobe.aem.guides</groupId>
                <artifactId>aem-guides-wknd.core</artifactId>
                <target>/apps/wknd/install</target>
            </embedded>
        </embeddeds>
        <subPackages>
            <subPackage>
                <groupId>com.adobe.cq</groupId>
                <artifactId>core.wcm.components.all</artifactId>
                <filter>true</filter>
            </subPackage>
            <subPackage>
                <groupId>com.adobe.cq</groupId>
                <artifactId>core.wcm.components.examples</artifactId>
                <filter>true</filter>
            </subPackage>
        </subPackages>
        </configuration>
    </plugin>
    
    
    
    Notice that core.wcm.components.all and core.wcm.components.examples are included as a subPackages . Inclusion of Core Components are explained later.
  3. Open the file ui.apps/src/main/content/META-INF/vault/filter.xml . This file contains the defines the paths that will be included and installed with the ui.apps package:
    <!-- ui.apps/src/main/content/META-INF/vault/filter.xml -->
    <?xml version="1.0" encoding="UTF-8"?>
    <workspaceFilter version="1.0">
        <filter root="/apps/wknd"/>
        <filter root="/apps/sling" />
    </workspaceFilter>
    
    
    

UI.content Module

ui.content maven module includes baseline content and configurations beneath /content and /conf . ui.content gets compiled into an AEM package much like ui.apps . The major difference is that the nodes stored in ui.content can be modified on the AEM instance directly. This includes pages, DAM assets, and editable templates. The ui.content module can be used to store sample content for a clean instance and/or to create some baseline configurations that are to be managed in source control.
  1. Open the file ui.content/src/main/content/META-INF/vault/filter.xml .
    This file contains the defines the paths that will be included and installed with the ui.content package. Notice that a mode="merge" attribute is added to the path. This ensures that the configurations deployed with a code deployment do not automatically override content or configurations that have been authored on the AEM instance directly.
    <!-- ui.content/src/main/content/META-INF/vault/filter.xml -->
    
    <?xml version="1.0" encoding="UTF-8"?>
    <workspaceFilter version="1.0">
        <filter root="/conf/wknd" mode="merge"/>
        <filter root="/content/wknd" mode="merge"/>
        <filter root="/content/dam/wknd" mode="merge"/>
    </workspaceFilter>
    
    
    
  2. Open the file ui.content/pom.xml .
    The ui.content module, like the ui.apps module, uses the FileVault Package plugin . Notice that an extra configuration property is added called acHandling , set to merge_preserve . This is included because the ui.content module includes Access Control Lists (ACLs) which are permissions, that determines who can edit the templates. In order for these ACLs to be imported into AEM the acHandling property is needed.
    <!-- ui.content/pom.xml -->
    <!-- ====================================================================== -->
                <!-- V A U L T   P A C K A G E   P L U G I N S                              -->
                <!-- ====================================================================== -->
                <plugin>
                    <groupId>org.apache.jackrabbit</groupId>
                    <artifactId>filevault-package-maven-plugin</artifactId>
                    <extensions>true</extensions>
                    <configuration>
                        <acHandling>merge_preserve</acHandling>
                    </configuration>
                </plugin>
    
    
    

Inclusion of Core Components

The project will leverage AEM Core Components. Earlier, when inspecting the deployed packages to AEM, multiple packages related to Core Components were included. Core Components are a set of base components designed to accelerate the development of an AEM Sites project. Core Components are open source and available on GitHub . More information about Core Components can be found here .
Core Components are installed in AEM automatically in the default runmode and used by the sample We.Retail site. In a production runmode ( nosamplecontent ) Core Components will not be available. In order to leverage them in all deployments it is a best practice to include them as part of the Maven project.
The AEM Project Archetype will include a version of AEM Core Components, however these projects have different release cycles, and thus the included version of Core Components may not be the latest. As a best practice, you should always look to leverage the latest version of Core Components. New features and bug fixes are updated frequently. The latest release information can be found on GitHub .
  1. View the dependencies section of aem-guides-wknd/pom.xml :
    A dependency for Core Components is added and a dependency for Core Component examples is added:
    <dependencies>
    ...
     <dependency>
         <groupId>com.adobe.cq</groupId>
         <artifactId>core.wcm.components.all</artifactId>
         <type>zip</type>
         <version>2.3.2</version>
    </dependency>
    <dependency>
         <groupId>com.adobe.cq</groupId>
         <artifactId>core.wcm.components.examples</artifactId>
         <type>zip</type>
         <version>2.3.2</version>
     </dependency>
    ...
    </dependencies>
    
    
    
  2. Update the version of Core Components from 2.3.2 to 2.4.0 by modifying the Core Component dependency versions in aem-guides-wknd/pom.xml :
    <dependencies>
    ...
    <dependency>
        <groupId>com.adobe.cq</groupId>
        <artifactId>core.wcm.components.all</artifactId>
        <type>zip</type>
        <version>2.4.0</version>
    </dependency>
    <dependency>
        <groupId>com.adobe.cq</groupId>
        <artifactId>core.wcm.components.examples</artifactId>
        <type>zip</type>
        <version>2.4.0</version>
    </dependency>
    ...
    </dependencies>
    
    
    
  3. View aem-guides-wknd/ui.apps/pom.xml :
    Notice the core.wcm.components.all and core.wcm.components.examples is included as a dependency in the dependency list. Notice also that a version is not included here. As a best practice, versions for dependencies are managed in the Parent Pom file.
    <!-- ui.apps/pom.xml -->
    <dependencies>
    ...
    <dependency>
       <groupId>com.adobe.cq</groupId>
        <artifactId>core.wcm.components.all</artifactId>
        <type>zip</type>
    </dependency>
     <dependency>
         <groupId>com.adobe.cq</groupId>
         <artifactId>core.wcm.components.examples</artifactId>
         <type>zip</type>
     </dependency>
    ...
    </dependencies>
    
    
    
  4. View the Vault Package Plugin within aem-guides-wknd/ui.apps/pom.xml :
    Notice that core.wcm.components.all and core.wcm.components.examples packages are included as a sub-package. This will deploy the Core Components package along with the WKND code each time.
    <!-- ui.apps/pom.xml -->
    <!-- ====================================================================== -->
    <!-- V A U L T   P A C K A G E   P L U G I N                                -->
    <!-- ====================================================================== -->
    <plugin>
         <groupId>org.apache.jackrabbit</groupId>
         <artifactId>filevault-package-maven-plugin</artifactId>
         <extensions>true</extensions>
         <configuration>
             <embeddeds>
                 <embedded>
                     <groupId>com.adobe.aem.guides</groupId>
                     <artifactId>aem-guides-wknd.core</artifactId>
                     <target>/apps/wknd/install</target>
                 </embedded>
             </embeddeds>
             <subPackages>
                 <subPackage>
                     <groupId>com.adobe.cq</groupId>
                     <artifactId>core.wcm.components.all</artifactId>
                     <filter>true</filter>
                 </subPackage>
                 <subPackage>
                     <groupId>com.adobe.cq</groupId>
                     <artifactId>core.wcm.components.examples</artifactId>
                     <filter>true</filter>
                 </subPackage>
             </subPackages>
         </configuration>
     </plugin>
    
    
    
    The core.wcm.components.examples are a set of sample pages that illustrate examples of the Core Components. As a best practice, when deploying a project for production use we recommend removing this dependency and subPackage inclusion.

(Optional) Add a Custom Thumbnail for the Package

This is an optional task but its nice to easily identify your custom code packages. You can do this by adding a custom thumbnail to the ui.apps module and when it is deployed to AEM it will show up in Package Manager.
  1. Create an image named thumbnail.png .
    The recommended dimensions are 64 x 64 pixels.
  2. Create a new folder named definition beneath: aem-guides-wknd/ui.apps/src/main/content/META-INF/vault/definition
    Add the thumbnail to the definition folder.
    As a sibling of thumbnail.png, inside the definition folder, add a file named .content.xml . Populate it with the following:
     <?xml version="1.0" encoding="UTF-8"?>
     <jcr:root xmlns:vlt="http://www.day.com/jcr/vault/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0">
         <thumbnail.png/>
     </jcr:root>
    
    
    
  3. Repeat the above steps to add the same custom thumbnail to the ui.content module.

Deploy the Project to AEM

  1. To test and verify our changes, once again run the following maven command from the project root:
    $ cd <src>/aem-guides-wknd
    $ mvn -PautoInstallPackage clean install
    ...
    [INFO] aem-guides-wknd .................................... SUCCESS [  0.369 s]
    [INFO] WKND Sites Project - Core .......................... SUCCESS [  3.836 s]
    [INFO] WKND Sites Project - UI apps ....................... SUCCESS [  3.172 s]
    [INFO] WKND Sites Project - UI content .................... SUCCESS [  0.554 s]
    [INFO] WKND Sites Project - Integration Tests Bundles ..... SUCCESS [  0.896 s]
    [INFO] WKND Sites Project - Integration Tests Launcher .... SUCCESS [  2.574 s]
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    
    
    
  2. Navigate to Package Manager in AEM.
    6 packages get installed. core.wcm.components.all includes 2 sub packages: core.wcm.components.config and core.wcm.components.content . The latest version of core.wcm.components.examples are also installed. You should now see the custom thumbnail for the WKND ui.apps and ui.content packages.

Source Control Management

It is always a good idea to use some form of source control to manage the code in your application. This tutorial uses git and GitHub. There are several files that get generated by Maven and/or the IDE of choice that should be ignored by the SCM.
Maven will create a target folder whenever you build and install the code package. The target folder and contents should be excluded from SCM.
Beneath ui.apps you will also notice many .content.xml files that are created. These XML files map the node types and properties of content installed in the JCR. These files are critical and should not be ignored except at the very root level.
The AEM project archetype will generates a sample .gitignore file that can be used as a starting point for which files can be safely ignored. The file is generated at <src>/aem-guides-wknd/.gitignore .

Using an Integrated Development Environment

There are multiple tools that can be used when developing with AEM:
In general Eclipse and IntelliJ tend to be preferred environments for Java development and Brackets is preferred by Front-end developers.
Popular developer workflow
This tutorial will use the Eclipse IDE and the AEM Developer tools plugin.
Note you will need Eclipse or an IDE setup. In this chapter and in the following chapter the Eclipse IDE with AEM Developer tool plugin will be used. Follow the instructions here to set up an integrated development environment .

Developer Workflow

High level developer workflow when working with AEM in a local environment
Developers will push and pull code and configurations between their local file system and an AEM instance running locally. Once code is tested thoroughly on the local AEM instance and all necessary code and configurations have been synced to file system the developer can then commit the code and push it to a shared SCM repository. From there the code can be integrated into the master code base and pushed to shared environments like Dev, QA...

Next Steps

Next part in the tutorial:
View the finished code on GitHub or download the finished package for this part of the tutorial: WKND Chapter Solutions