Maven Artifact Naming Conventions for AEM Binaries


Unfortunately Adobe does not publish their product binaries (e.g. Quickstart JAR, Hotfixes, Service Packs etc.) within a Maven Artifact Repository that is accessible to AEM customers or partners.

But for Deployment Automation e.g. with DevOps CONGA or Ansible haven these binaries available in a structured way is very important. Using a Maven Artifact Repository fulfills the requirements, and also adds the possibility to cache much-used artifacts locally.

This guideline describes a naming convention for Group IDs and Artifact IDs how these files should be published in your local (and protected) Artifact Repository. Once deployed using this convention they can be used by all tooling and configuration definition that adheres to this convention. (But you still have to upload the artifacts manually to have them ready-to-use.)

Types of AEM binaries

We distinguish between the following types of binaries (can be downloaded from Adobe Software Distribution Portal):

  • AEM SDK - ZIP file for AEMaaCS containing Quickstart JAR and further tools.
  • AEM SDK Add-Ons and Tools - Content package ZIP files for AEM SDK
  • AEM Quickstart - main JAR to install and startup AEM
  • AEM Hotfixes, Feature Packs and Service Packs - for AEM 6.5 and below
  • AEM Dispatcher - can be downloaded from AEM Dispatcher Release Notes

Within the Maintenance Release Vehicle Definitions Adobe describes different package types:

  • Full Release (Quickstart)
  • Service Pack (SP)
  • Cumulative Fix Pack (CFP)
  • Cumulative Oak Fix Pack (COFP)
  • Hotfix (HF)
  • Feature Pack (FP)
  • Overlay

Separation from artifacts published by Adobe

Adobe publishes it's artifacts with Group IDs com.adobe.* and*.

To clearly separate the "self-created" artifacts we use our own "namespace" by using Group IDs starting with adobe.binary.aem.*

Artifact Naming Convention

Binary TypeGroup IDArtifact IDClassifierVersionExtension
Full Release (Quickstart)adobe.binary.aem.<aem-version>.quickstartaem-quickstart
From Quickstart JARjar
Service Pack (SP)adobe.binary.aem.<aem-version>.servicepackPackage name without version
Package Versionzip
Cumulative Fix Pack (CFP)adobe.binary.aem.<aem-version>.cumulativefixpackPackage name without version
Package Versionzip
Oak Cumulative Fix Pack (COFP)adobe.binary.aem.<aem-version>.cumulativeoakfixpackPackage name without version
Package Versionzip

Hotfix (HF)

adobe.binary.aem.<aem-version>.hotfixPackage name without version
Package Versionzip
Feature Pack (FP)adobe.binary.aem.<aem-version>.featurepackPackage name without version
Package Versionzip
Overlayadobe.binary.aem.<aem-version>.overlayPackage name without version
Package Versionzip
AEM Dispatcheradobe.binary.aem.dispatcherdispatcherPlatform identifierVersiontar.gz or zip
AEM SDKadobe.binary.aem.<aem-version>.sdkPackage name without version
Package Versionzip
AEM SDK Add-Onadobe.binary.aem.<aem-version>.addonPackage name without version
Package Versionzip
Othersadobe.binary.aem.<aem-version>.toolingPackage name without version
Package Versionzip


  • <aem-version> is the first two digits of the AEM version number e.g. "63", "64", "65" or "cloud" for AEMaaCS
  • We put Hotfix (HF) and Oak Cumulative Fix Pack (COFP) in the same group because the package names for COFP are also named "hofix"
  • Examples for splitting up a package file name from Adobe into Artifact ID and Version:
    • => Artifact ID AEM-CFP-, Version: 2.0
    • => Artifact ID: cq-6.3.0-hotfix-17649, Version: 1.0
    • => Artifact ID: AEM-6.2-Service-Pack-1, Version: 6.2.SP1
  • For dispatcher the "Platform" makes up the string after between "dispatcher" and the version name - examples:
    • dispatcher-apache2.4-linux-i686-ssl-4.2.2.tar.gz => Artifact ID: dispatcher, Classifier: apache2.4-linux-i686-ssl, Version: 4.2.2, Extension: tar.gz
    • => Artifact ID: dispatcher, Classifier: iis-windows-x64, Version: 4.2.2, Extension: zip
  • It is recommended to upload for Hotfixes also a readme.txt file containing a hint about what is contained in the hotfix (e.g. description from package share, list of issues that was fixed). Use same Maven coordinates as the hotfix package, plus readme as classifier and txt as extension.
  • It is questionable if overlays should be deployed as individual artifact in the Maven Artifact Repository. It may make more sense to include them in the delivery package of your application.
  • AEM Packages may define dependencies to other AEM packages validated by AEM package manager when uploading the package. These dependencies are not reflected in the POMs of the uploaded artifacts.


Examples for Dependencies following this convention:

<!-- Full Release -->

<!-- Service Pack -->

<!-- Cumulative Fix Pack -->

<!-- Cumulative Oak Fix Pack -->

<!-- Hotfix -->

<!-- Feature Pack -->

<!-- Dispatcher -->

Automatically generate Artifact Coordinates

You can use this tool to generate the artifact coordinates automatically for a given filename:

The tools uses some heuristics to detect the property file type automatically.