Dopo il passaggio da Java™ 8 a Java™ 11, la build restituisce un errore relativo a RequireJavaVersion. Cosa posso fare?
Per le build di Cloud Manager è possibile che l’esecuzione di maven-enforcer-plugin non riesca e generi questo errore.
"[main] [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion".
Si tratta di un problema noto dovuto al fatto che Cloud Manager utilizza una versione diversa di Java™ per eseguire il comando maven per la compilazione del codice. Basta omettere requireJavaVersion dalle configurazioni del maven-enforcer-plugin.
Il controllo di qualità del codice non riuscito e la distribuzione è bloccata. C’è un modo per aggirare questo controllo?
Sì. Tutti gli errori generati dal controllo di qualità del codice, a eccezione della valutazione di sicurezza, riguardano metriche non critiche e possono pertanto essere ignorati come parte di una pipeline di distribuzione espandendo gli elementi nell’interfaccia utente dei risultati.
L’utente con il ruolo Responsabile dell’implementazione, Responsabile del progetto o Proprietario business può ignorare i problemi (facendo in tal caso procedere la pipeline) o accettarli (causando in tal caso l’arresto della pipeline con un errore).
Per ulteriori informazioni, consulta i documenti Test di qualità del codice e Configurazione delle pipeline non di produzione.
Posso usare SNAPSHOT per la versione del progetto Maven?
Sì. Per le distribuzioni nell’ambiente di sviluppo, i file pom.xml del ramo Git devono contenere -SNAPSHOT dopo il valore <version>.
Questo valore consente di installare la distribuzione successiva anche se la versione non è stata modificata. Per le distribuzioni nell’ambiente di sviluppo, non viene aggiunta né generata una versione automatica della build Maven.
È possibile impostare la versione su -SNAPSHOT per le build o le implementazioni negli ambienti di staging e produzione. Cloud Manager imposta automaticamente un numero di versione corretto e crea un tag in Git per l’utente. Se necessario, è possibile fare riferimento a questo tag in un secondo momento.
Per ulteriori dettagli sulla gestione delle versioni, consulta Gestione delle versioni dei progetti Maven.
Come funziona il controllo delle versioni di pacchetti e bundle per le distribuzioni negli ambienti di staging e produzione?
Nelle distribuzioni in ambienti di staging e produzione, viene generata una versione automatica: consulta Gestione delle versioni dei progetti Maven.
Per il controllo delle versioni personalizzato per le distribuzioni negli ambienti di staging e produzione, imposta una versione Maven in tre parti appropriata, come ad esempio 1.0.0. Aumenta il numero della versione per ogni esecuzione della distribuzione nell’ambiente di produzione.
Cloud Manager aggiunge automaticamente la versione alle build di staging e produzione e crea un ramo Git. Non è richiesta alcuna configurazione speciale. Se non si imposta una versione maven come descritto in precedenza, la distribuzione avviene comunque e viene impostata una versione automaticamente.
L’esecuzione della build Maven non riesce per le distribuzioni di Cloud Manager, ma a livello locale non genera errori. Qual è il problema?
Per ulteriori informazioni, fai riferimento a questa risorsa Git.
Cosa posso fare se l’esecuzione di una distribuzione di Cloud Manager non riesce al passaggio di distribuzione in AEM as a Cloud Service?
Il motivo più comune che causa la mancata esecuzione di una distribuzione è l’assenza di autorizzazioni sufficienti dell’utente sling-distribution-importer. In questa situazione, il passaggio di distribuzione durante una distribuzione di Cloud Manager non riesce e vengono generati errori come quelli indicati di seguito.
[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’utente sling-distribution-importer deve disporre di autorizzazioni aggiuntive per i percorsi contenuto definiti in ui.content package. In genere, questo significa che è necessario aggiungere le autorizzazioni per /conf e /var.
La soluzione per aggiungere gli elenchi di controllo accesso (ACL) per l’utente sling-distribution-importer è aggiungere uno script di configurazione OSGi RepositoryInitializer nel pacchetto di distribuzione delle app.
Nell’errore precedente, il pacchetto myapp-base.ui.content-*.zip include contenuti in /conf e /var/workflow. Affinché la distribuzione venga eseguita correttamente, è necessario che sling-distribution-importer disponga delle autorizzazioni in questi percorsi.
Di seguito è riportato un esempio di configurazione OSGi org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config che consente di aggiungere ulteriori autorizzazioni per l’utente sling-distribution-importer. La configurazione aggiunge le autorizzazioni in /var. Tale configurazione deve essere aggiunta al pacchetto dell’applicazione in /apps/myapp/config (dove myapp è la cartella in cui è archiviato il codice dell’applicazione).