Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Overview

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 wcm.io 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:

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 com.day.*.

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

Remarks:

  • <aem-version> is the first two digits of the AEM version number e.g. "61", "62", "63"
  • 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:
    • AEM-CFP-6.3.0.2-2.0.zip => Artifact ID AEM-CFP-6.3.0.2, Version: 2.0
    • cq-6.3.0-hotfix-17649-1.0.zip => Artifact ID: cq-6.3.0-hotfix-17649, Version: 1.0
    • AEM-6.2-Service-Pack-1-6.2.SP1.zip => 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
    • dispatcher-iis-windows-x64-4.2.2.zip => 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

Examples for Dependencies following this convention:

<!-- Full Release -->
<dependency>
  <groupId>adobe.binary.aem.63.quickstart</groupId>
  <artifactId>aem-quickstart</artifactId>
  <version>6.3.0</version>
</dependency>

<!-- Service Pack -->
<dependency>
  <groupId>adobe.binary.aem.62.servicepack</groupId>
  <artifactId>AEM-6.2-Service-Pack-1-6.2.SP1</artifactId>
  <version>1.0</version>
  <type>zip</type>
</dependency>

<!-- Cumulative Fix Pack -->
<dependency>
  <groupId>adobe.binary.aem.63.cumulativefixpack</groupId>
  <artifactId>AEM-CFP-6.3.0.2</artifactId>
  <version>2.0</version>
  <type>zip</type>
</dependency>

<!-- Cumulative Oak Fix Pack -->
<dependency>
  <groupId>adobe.binary.aem.63.cumulativeoakfixpack</groupId>
  <artifactId>cq-6.3.0-hotfix-17649</artifactId>
  <version>1.0</version>
  <type>zip</type>
</dependency>

<!-- Hotfix -->
<dependency>
  <groupId>adobe.binary.aem.62.hotfix</groupId>
  <artifactId>cq-6.2.0-hotfix-12785</artifactId>
  <version>7.0</version>
  <type>zip</type>
</dependency>

<!-- Feature Pack -->
<dependency>
  <groupId>adobe.binary.aem.61.featurepack</groupId>
  <artifactId>AEM-6.1-Communities-Livefyre-Feature-Pack-7-HF1</artifactId>
  <version>1.8.557.3</version>
  <type>zip</type>
</dependency>

<!-- Dispatcher -->
<dependency>
  <groupId>adobe.binary.aem.dispatcher</groupId>
  <artifactId>dispatcher</artifactId>
  <classifier>apache2.4-linux-i686-ssl</classifier>
  <version>4.2.2</version>
  <type>tar.gz</type>
</dependency>
  • No labels