The package manager is a GUI-friendly way to manage “packages” within your project. What are “packages” exactly? What’s inside the .zip files? How does the Maven build process define what goes where, what the package is named,.. etc. I’m here to answer all those questions for you!

Back-End | OSGi Bundles: core/

Good ‘ol Java. I don’t know about you, but (..I’m probably dating myself here) a lot of my college coursework was done in Java. So when I moved into the AEM scene, everything was fairly familiar to me. I’m old, so that may no longer be the case for upcoming developers. You’ll have to let me know on that one. ;)

The core bundle is where all of your Java code should live. If you’ve been doing any sort of small component building in AEM, you probably have already become familiar with Sling Models. Sling Models are the literal model of your component. They contain the structure of what your component will become. I’ll go into greater detail about Sling Models later, but for the purpose of this tutorial it’s good to just know that they exist and where they exist.

Again, in current AEM archetypes your Java code will live under the core/ directory. If you’re working on an older project however, you may not see a core/ at the root of your project at all, and instead see a different directory like packages/. Java files were separated out in later archetypes for a variety of reasons. Listing a few: to create a greater separation of logic and dependency management, and to have a clearer distinction between FE (ui.apps HTL models) and BE (Sling models).

Bottom line: as long as declarations match in the pom.xml, Sling models can technically go anywhere a developer wants to put them! Yikes... Archetypes now streamline this to:

core/src/main/java

In larger projects they may be further organized by packages like servlets or services. In this example, my Sling models live here (and I will have no further splits):

core/src/main/java/com//aem/core

Front-End: ui.apps/ & ui.frontend/

Some text here about front end folders and what goes inside. Brief. They are content packages.

Defining a Package

OSGi Bundle

Include a bnd.bnd file

Content Packages:

Include a filter.xml file

The filter.xml is the blueprint of the package. It tells maven what to include or exclude during the build process. Each folder that needs to create a .zip content package (ui.apps, ui.frontend, etc.) will need to have one defined in order for the package to be built and sent to the package manager.

Maven has some built in restrictions as well that helps keep things clean, and runs a few sanity checkers for you. That doesn’t mean it’s a free for all, though. Directories and filters have to make sense.

pom.xml : Maven Configurations & Dependencies

Some info about pom files.

What’s inside the .zips?

your-site-aem.all-1.0.0-SNAPSHOT.zip
├── META-INF/
│   ├── vault/
│   │   ├── filter.xml (defines /apps/your-site-packages)
│   │   └── properties.xml (package metadata)
│   └── MANIFEST.MF
├── jcr_root/
│   └── apps/
│       └── your-site-packages/
│           ├── application/
│           │   └── install/
│           │       ├── your-site-aem.ui.apps-1.0.0-SNAPSHOT.zip
│           │       ├── your-site-aem.core-1.0.0-SNAPSHOT.jar
│           │       ├── your-site-aem.ui.config-1.0.0-SNAPSHOT.zip
│           │       └── [vendor bundles]
│           └── content/
│               └── install/
│                   └── your-site-aem.ui.content-1.0.0-SNAPSHOT.zip
└── [sub-packages from Core Components, ACS Commons]

In A Nutshell!

Source Code
    ↓
Maven Build (mvn clean install)
    ↓
Individual Packages Created (core.jar, ui.apps.zip, ui.content.zip, etc.)
    ↓
Container Package (all.zip) Embeds Everything
    ↓
Adobe Pipeline Uploads ZIP to Package Manager
    ↓
Package Manager (/crx/packmgr/service.jsp) Receives Package
    ↓
Package Installed & Activated in AEM Repository