Ma version échoue et affiche une erreur concernant RequireJavaVersion, après le passage de Java™ 8 à Java™ 11. Que puis-je faire ?
Pour les builds Cloud Manager, le maven-enforcer-plugin peut échouer avec cette erreur.
"[main] [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion".
Cette erreur est un problème connu dû au fait que Cloud Manager utilisait une version différente de Java™ pour exécuter la commande maven plutôt que de compiler le code. Omettez simplement requireJavaVersion de vos configurations maven-enforcer-plugin.
La vérification de la qualité du code a échoué et le déploiement est bloqué. Y a-t-il un moyen de contourner cette vérification ?
Oui. Tous les échecs de vérification liés à la qualité du code, à l’exception de l’évaluation de la sécurité, ne sont pas des mesures critiques. Ils peuvent donc être contournés, dans le cadre d’un pipeline de déploiement, en développant les éléments dans l’interface utilisateur des résultats.
Un utilisateur ayant un rôle de responsable de déploiement, responsable de projet ou propriétaire d’entreprise peut, au choix, contourner les problèmes, auquel cas le pipeline continue, ou les accepter, auquel cas le pipeline s’arrête avec un échec.
Voir les documents Test de qualité du code et Configurer des pipelines hors production pour plus d’informations.
Puis-je utiliser SNAPSHOT pour la version du projet Maven ?
Oui. Pour les déploiements de développeurs, les fichiers pom.xml de la branche Git doivent contenir -SNAPSHOT à la fin de la valeur <version>.
Cette valeur permet de conserver les déploiements ultérieurs alors que la version n’a pas été modifiée. Pour les déploiements de développeurs, aucune version automatique n’est ajoutée ou générée pour la build maven.
Vous pouvez également définir la version sur -SNAPSHOT pour les builds ou déploiements d’évaluation et de production. Cloud Manager définit automatiquement un numéro de version approprié et crée pour vous une balise dans git. Cette balise peut être référencée ultérieurement, le cas échéant.
Pour plus d’informations sur la gestion des versions, voir la section Gestion des versions du projet Maven.
Comment le contrôle de version des packages et des lots fonctionne-t-il pour les déploiements d’évaluation et de production ?
En cas de déploiements d’évaluation et de production, une version automatique est générée - voir la section Gestion des versions du projet Maven.
Pour le contrôle de version personnalisé dans les déploiements d’évaluation et de production, définissez une version maven en trois parties, telle que 1.0.0. Passez à la version supérieure à chaque déploiement en production.
Cloud Manager ajoute automatiquement sa version aux builds d’évaluation et de production et crée même une branche Git. Aucune configuration spécifique n’est nécessaire. Si vous ne définissez pas de version Maven comme décrit précédemment, le déploiement s’effectue quand même et une version est automatiquement définie.
Ma build Maven échoue lors des déploiements de Cloud Manager, mais elle est pourtant créée localement sans la moindre erreur. Qu’est-ce qui ne va pas ?
Consultez cette ressource git pour plus d’informations.
Que faire si le déploiement de Cloud Manager échoue lors de l’étape de déploiement dans AEM as a Cloud Service ?
La raison la plus courante de l’échec des déploiements résulte d’autorisations insuffisantes pour l’utilisateur sling-distribution-importer. Dans ce cas, l’étape de déploiement échoue lors d’un déploiement de Cloud Manager et des erreurs telles que les suivantes sont générées.
[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.
L’utilisateur ou l’utilisatrice sling-distribution-importer a besoin d’autorisations supplémentaires pour les chemins de contenu définis dans ui.content package. Cette règle signifie généralement qu’il faut ajouter des autorisations pour /conf et /var.
La solution consiste à ajouter un script de configuration RepositoryInitializer OSGi à votre package de déploiement d’applications afin d’ajouter des listes de contrôle d’accès pour l’utilisateur sling-distribution-importer.
Dans l’exemple d’erreur précédent, le package myapp-base.ui.content-*.zip inclut le contenu situé sous /conf et /var/workflow. Pour que le déploiement réussisse, les autorisations pour sling-distribution-importer sous ces chemins d’accès sont nécessaires.
Voici un exemple org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config de configuration OSGi qui permet d’ajouter des autorisations supplémentaires pour l’utilisateur ou l’utilisatrice sling-distribution-importer. Cette configuration ajoute des autorisations sous /var. Une telle configuration doit être ajoutée au package d’application sous /apps/myapp/config (où myapp est le dossier dans lequel le code de votre application est stocké).