Scopri come creare progetti AEM con Maven e gli standard da osservare durante la creazione di un progetto personalizzato.
Per generare e distribuire correttamente con Cloud Manager, i progetti AEM devono rispettare le seguenti linee guida:
pom.xml
. Il file pom.xml
può fare riferimento a tutti i sottomoduli (che a loro volta possono avere altri sottomoduli e così via), a seconda delle necessità.pom.xml
.
.zip
del pacchetto di contenuti, che si trovano in una directory denominata target
.
.zip
(presenti anche nella directory denominata target
), le cui directory sono conf
e conf.d
.In alcuni casi limitati, potrebbe essere necessario modificare leggermente il processo di build durante l’esecuzione in Cloud Manager rispetto a quando viene eseguito dalle workstation di sviluppo. Per questi casi è possibile utilizzare i profili Maven per definire il modo in cui la build deve differire nei diversi ambienti, incluso Cloud Manager.
L’attivazione di un profilo Maven all’interno dell’ambiente di build di Cloud Manager deve essere eseguita cercando la CM_BUILD
variabile di ambiente. Analogamente, per un profilo destinato a essere utilizzato esclusivamente al di fuori dell’ambiente di build di Cloud Manager, è necessario verificare l’assenza di tale variabile.
Ad esempio, per inviare un semplice messaggio solo quando la build viene eseguita in Cloud Manager, effettua questa operazione.
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<target>
<echo>I'm running inside Cloud Manager!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Per eseguire test di questo profilo da una workstation di sviluppo, è possibile abilitarlo nella riga di comando (con -PcmBuild
) o nell’ambiente di sviluppo integrato (IDE).
Per inviare un semplice messaggio solo quando la build viene eseguita all’esterno di Cloud Manager, effettua questa operazione.
<profile>
<id>notCMBuild</id>
<activation>
<property>
<name>!env.CM_BUILD</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<target>
<echo>I'm running outside Cloud Manager!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Gli artefatti di un archivio Maven protetto da password devono essere utilizzati con cautela, in quanto attualmente il codice distribuito tramite questo meccanismo non viene eseguito da tutte le regole per la qualità del codice implementate nei gate di qualità di Cloud Manager. Per questo motivo, è consigliabile utilizzarlo esclusivamente in rari casi e solo per il codice non collegato a AEM. Si consiglia inoltre di distribuire le origini Java e l’intero codice sorgente del progetto insieme al binario.
Per utilizzare un archivio Maven protetto da password in Cloud Manager:
.cloudmanager/maven/settings.xml
nell’archivio Git, che segue lo schema del file delle impostazioni Maven.All’avvio del processo di build di Cloud Manager:
<servers>
in questo file viene unito al file predefinito settings.xml
fornito da Cloud Manager.
adobe
e cloud-manager
sono considerati riservati e non devono essere utilizzati per i server personalizzati.central
, il mirroring non viene mai eseguito da Cloud Manager.<repository>
e/o da un elemento del <pluginRepository>
contenuto nel file pom.xml
.<repository>
e/o di <pluginRepository>
sono contenuti in un profilo specifico di Cloud Manager, anche se ciò non è strettamente necessario.Supponiamo ad esempio che l’archivio si trovi nella posizione https://repository.myco.com/maven2
e che il nome utente che Cloud Manager debba utilizzare sia cloudmanager
, con password secretword
. Effettua le seguenti operazioni.
Imposta la password come segreto nella pipeline.
$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword`
Fai riferimento al segreto dal file .cloudmanager/maven/settings.xml
.
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="https://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<server>
<id>myco-repository</id>
<username>cloudmanager</username>
<password>${env.CUSTOM_MYCO_REPOSITORY_PASSWORD}</password>
</server>
</servers>
</settings>
Infine, fai riferimento all’ID server nel file pom.xml
:
<profiles>
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<repositories>
<repository>
<id>myco-repository</id>
<name>MyCo Releases</name>
<url>https://repository.myco.com/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>myco-repository</id>
<name>MyCo Releases</name>
<url>https://repository.myco.com/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
È buona prassi distribuire le origini Java insieme ai dati binari in un archivio Maven.
Per eseguire l’operazione, configura il plug-in maven-source nel progetto.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
È buona prassi distribuire l’intera origine del progetto insieme ai dati binari in un archivio Maven. Questo permette di rigenerare l’artefatto in modo esatto.
Per eseguire l’operazione, configura il plug-in maven-assembly nel progetto.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>project-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>project</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
In Cloud Manager le build possono produrre qualsiasi numero di pacchetti di contenuti. Per diversi motivi può essere utile produrre un pacchetto di contenuti ma non distribuirlo. Un esempio potrebbe essere la creazione di pacchetti di contenuto utilizzati solo per il test o che vengono reinseriti nel pacchetto da un altro passaggio del processo di compilazione, ovvero un pacchetto secondario di un altro pacchetto.
Per soddisfare questi scenari, Cloud Manager cerca una proprietà denominata cloudManagerTarget
tra le proprietà dei pacchetti di contenuto della build. Se questa proprietà è impostata su none
, il pacchetto viene ignorato e non distribuito.
Il meccanismo per impostare questa proprietà dipende dal modo in cui la build produce il pacchetto di contenuti. Ad esempio, con filevault-maven-plugin
è possibile configurare il plug-in come indicato di seguito.
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
<!-- other configuration -->
</configuration>
</plugin>
content-package-maven-plugin
presenta una configurazione analoga.
<plugin>
<groupId>com.day.jcr.vault</groupId>
<artifactId>content-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
<!-- other configuration -->
</configuration>
</plugin>
In molti casi, lo stesso codice viene distribuito in più ambienti AEM. Quando possibile, Cloud Manager evita di ricompilare la base di codice quando rileva che lo stesso commit Git viene utilizzato in più esecuzioni di pipeline full stack.
All’avvio di un’esecuzione, viene estratto il commit HEAD corrente per la pipeline del ramo. L’hash del commit è visibile nell’interfaccia utente e tramite l’API. Al termine della fase di build, gli artefatti risultanti vengono archiviati in base a tale hash di commit e possono essere riutilizzati nelle esecuzioni successive della pipeline.
Se si trovano nello stesso programma, i pacchetti vengono riutilizzati tra le pipeline. Durante la ricerca di pacchetti da poter riutilizzare, AEM ignora i rami e riutilizza gli artefatti tra rami.
In caso di un riutilizzo, i passaggi di build e qualità del codice vengono effettivamente sostituiti con i risultati dell’esecuzione originale. Il file di registro della fase di build elenca gli artefatti e le informazioni sull’esecuzione utilizzate per generarli originariamente.
Di seguito è riportato un esempio di tale output di registro.
The following build artifacts were reused from the prior execution 4 of pipeline 1 which used commit f6ac5e6943ba8bce8804086241ba28bd94909aef:
build/aem-guides-wknd.all-2021.1216.1101633.0000884042.zip (content-package)
build/aem-guides-wknd.dispatcher.cloud-2021.1216.1101633.0000884042.zip (dispatcher-configuration)
Il registro del passaggio di qualità del codice conterrà informazioni simili alle seguenti.
Ipotizza di utilizzare un programma con due pipeline di sviluppo:
foo
bar
Entrambi i rami presentano lo stesso ID commit.
Ipotizza di utilizzare un programma con due rami:
foo
bar
Entrambi i rami presentano lo stesso ID commit.
foo
.bar
.In questo caso, l’artefatto da foo
viene riutilizzato per la pipeline di produzione poiché è stato identificato lo stesso hash del commit.
Se lo desideri, puoi disattivare il comportamento di riutilizzo per specifiche pipeline impostando la variabile di pipeline CM_DISABLE_BUILD_REUSE
su true
. Se questa variabile è impostata, l’hash del commit viene ancora estratto e gli artefatti risultanti vengono archiviati per un utilizzo successivo, ma gli eventuali artefatti archiviati in precedenza non verranno riutilizzati. Per comprendere questo comportamento, considera lo scenario seguente.
becdddb
. L’esecuzione ha esito positivo e gli artefatti risultanti vengono archiviati.CM_DISABLE_BUILD_REUSE
.becdddb
, non vengono riutilizzati per via della variabile CM_DISABLE_BUILD_REUSE
.f6ac5e6
. L’esecuzione ha esito positivo e gli artefatti risultanti vengono archiviati.CM_DISABLE_BUILD_REUSE
viene eliminata.f6ac5e6
, questi artefatti vengono riutilizzati.CM_DISABLE_BUILD_REUSE
non vengono considerate quando Cloud Manager opta per riutilizzare gli artefatti di generazione creati in precedenza.