Dieses Dokument enthält Antworten auf die am häufigsten gestellten Fragen zu Cloud Manager in AEM as a Cloud Service.
Ja. Fügen Sie die maven-toolchains-plugin
mit den richtigen Einstellungen für Java™ 11.
Der Prozess wird hier dokumentiert.
Ein Beispiel finden Sie unter WKND-Beispielprojekt-Code.
Ihr AEM Cloud Manager-Build schlägt möglicherweise fehl, wenn versucht wird, den Build von Java™ 8 auf 11 zu wechseln. Wenn der folgende Fehler auftritt, müssen Sie maven-scr-plugin
und konvertieren Sie alle OSGi-Anmerkungen in OSGi R6-Anmerkungen.
[main] [ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.26.4:scr (generate-scr-scrdescriptor) on project helloworld.core: /build_root/build/testsite/src/main/java/com/adobe/HelloWorldServiceImpl.java : Unable to load compiled class: com.adobe.HelloWorldServiceImpl: com/adobe/HelloWorldServiceImpl has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 -> [Help 1]
Anweisungen zum Entfernen dieses Plug-ins finden Sie hier.
Bei Cloud Manager-Builds kann das maven-enforcer-plugin
mit diesem Fehler fehlschlagen.
"[main] [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion".
Dieser Fehler ist ein bekanntes Problem, da Cloud Manager eine andere Version von Java™ verwendet, um den Maven-Befehl im Vergleich zum Kompilierungscode auszuführen. Lassen Sie einfach requireJavaVersion
in den Konfigurationen Ihres maven-enforcer-plugin
weg.
Ja. Alle Fehler bei der Überprüfung der Code-Qualität mit Ausnahme der Sicherheitseinstufung sind nicht kritische Metriken, sodass sie als Teil einer Bereitstellungs-Pipeline übersprungen werden können, indem die Elemente in der Ergebnis-Benutzeroberfläche erweitert werden.
Benutzer mit der Rolle Bereitstellungs-Manager, Projekt-Manager oder Geschäftsinhaber können die Probleme außer Kraft setzen. In diesem Fall wird die Pipeline fortgesetzt. Sie können die Probleme aber auch akzeptieren. In diesem Fall stoppt die Pipeline mit einem Fehler.
Weitere Informationen finden Sie in den Dokumenten Testen der Code-Qualität und Konfigurieren von Nicht-Produktions-Pipelines.
Ja. Bei Entwicklerbereitstellungen müssen die pom.xml
-Dateien der Git-Verzweigung am Ende des <version>
-Werts -SNAPSHOT
enthalten.
Mit diesem Wert kann die nachfolgende Bereitstellung weiterhin installiert werden, wenn sich die Version nicht geändert hat. In Entwicklerbereitstellungen wird keine automatische Version für den Maven-Build hinzugefügt oder generiert.
Sie können die Version für Staging- und Produktions-Builds oder -Bereitstellungen auch auf -SNAPSHOT
setzen. Cloud Manager legt automatisch eine geeignete Versionsnummer fest und erstellt für Sie in Git ein Tag. Auf dieses Tag kann bei Bedarf später verwiesen werden.
Weitere Informationen zur Versionsverwaltung finden Sie hier dokumentiert.
In Staging- und Produktionsimplementierungen wird eine automatische Version wie hier dokumentiert.
Für die benutzerdefinierte Versionierung in Staging- und Produktionsbereitstellungen legen Sie eine korrekte dreiteilige Maven-Version wie 1.0.0
fest. Erhöhen Sie die Version jedes Mal, wenn Sie sie in der Produktion bereitstellen.
Cloud Manager fügt Staging- und Produktions-Builds automatisch eine eigene Version hinzu und erstellt sogar eine Git-Verzweigung. Es ist keine spezielle Konfiguration notwendig. Wenn Sie keine Maven-Version wie zuvor beschrieben festlegen, ist die Bereitstellung weiterhin erfolgreich und eine Version wird automatisch festgelegt.
Weitere Informationen dazu finden Sie in dieser Git-Ressource.
Der häufigste Grund für fehlgeschlagene Bereitstellungen liegt in unzureichenden Berechtigungen für den sling-distribution-importer
-Benutzer. In diesem Fall schlägt der Bereitstellungsschritt während einer Cloud Manager-Implementierung fehl und es werden Fehler wie die folgenden erzeugt.
[Queue Processor for Subscriber agent forwardPublisherSubscriber] org.apache.jackrabbit.vault.fs.io.Importer Error while committing changes. Retrying import from checkpoint at /. Retries 4/10
[Queue Processor for Subscriber agent forwardPublisherSubscriber] org.apache.sling.distribution.journal.impl.subscriber DistributionSubscriber Error processing queue item
org.apache.sling.distribution.common.DistributionException: Error processing distribution package
dstrpck-1583514457813-c81e7751-2da6-4d00-9814-434187f08d32. Retry attempts 162/infinite.
Caused by: org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session.
Caused by: javax.jcr.AccessDeniedException: OakAccess0000: Access denied [EventAdminAsyncThread #7] org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher [null] Error processing distribution package` `dstrpck-1583514457813-c81e7751-2da6-4d00-9814-434187f08d32. Retry attempts 344/infinite. Message: Error trying to extract package at path /etc/packages/com.myapp/myapp-base.ui.content-5.1.0-SNAPSHOT.
Der sling-distribution-importer
-Benutzer benötigt zusätzliche Berechtigungen für die im ui.content package
definierten Inhaltspfade. Diese Regel bedeutet normalerweise, dass Berechtigungen für beide /conf
und /var
.
Die Lösung besteht darin, Ihrem Programm-Bereitstellungspaket ein RepositoryInitializer OSGi-Konfigurations-Skript hinzuzufügen, um ACLs für die sling-distribution-importer
-Benutzerinnen und -Benutzer hinzuzufügen.
Im obigen Beispielfehler enthält das Paket myapp-base.ui.content-*.zip
Inhalte unter /conf
und /var/workflow
. Damit die Bereitstellung erfolgreich ist, müssen Berechtigungen für die sling-distribution-importer
unter diesen Pfaden benötigt.
Hier ist ein Beispiel für eine org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config
-OSGi-Konfiguration, die zusätzliche Berechtigungen für sling-distribution-importer
-Benutzerinnen und -Benutzer hinzufügt. Die Konfiguration fügt Berechtigungen unter /var
hinzu. Eine solche Konfiguration muss dem Anwendungspaket unter /apps/myapp/config
hinzugefügt werden (wobei myapp der Ordner ist, in dem Ihr Anwendungscode gespeichert ist).
Wenn das Hinzufügen einer OSGi-Konfiguration für RepositoryInitializer den Fehler nicht behoben hat, kann dies auf eines dieser zusätzlichen Probleme zurückzuführen sein.
Die Bereitstellung schlägt möglicherweise aufgrund einer fehlerhaften OSGi-Konfiguration fehl, die einen vorkonfigurierten Service beschädigt.
Die Bereitstellung kann aufgrund fehlerhafter Dispatcher- oder Apache-Konfigurationen fehlschlagen.
Die Bereitstellung könnte aufgrund eines anderen Fehlers während der Replikation der Inhaltspakete (Sling-Verteilung) vom den Autoren- zu den Veröffentlichungsinstanzen fehlschlagen.
Sie können eine 403
Fehler wie der folgende, wenn versucht wird, Pipeline-Variablen über aio
Befehle.
$ aio cloudmanager:list-pipeline-variables 222
Cannot get variables: https://cloudmanager.adobe.io/api/program/111/pipeline/222/variables (403 Forbidden)
$ aio cloudmanager:set-pipeline-variables 222 --variable TEST 1
Cannot get variables: https://cloudmanager.adobe.io/api/program/111/pipeline/222/variables (403 Forbidden)
$ aio cloudmanager:set-environment-variables 1755 --variable TEST 1
setting variables... !
Cannot set variables: https://cloudmanager.adobe.io/api/program/111/environment/222/variables (403 Forbidden)
In diesem Fall muss der Benutzer, der diese Befehle ausführt, zum Bereitstellungsmanager Rolle in der Admin Console.
Weitere Informationen finden Sie unter API-Berechtigungen.