Utilizzo di Archetipo progetto AEM

Ultimo aggiornamento: 2024-02-13
  • Creato per:
  • Developer
    Admin

Questo documento spiega come utilizzare l’archetipo di progetto AEM per creare un progetto Adobe Experience Manager minimo basato su best practice come punto di partenza per i tuoi progetti AEM.

Si concentra sui pattern di utilizzo generali e su ciò che l’archetipo fa per te. Per opzioni di build e istruzioni tecniche dettagliate, consulta la documentazione nell’archivio GitHub dell’archetipo.

SUGGERIMENTO

La versione più recente dell’Archetipo progetto AEM è disponibile su GitHub.

Guida introduttiva

L’archetipo del progetto rende facile iniziare a sviluppare in AEM. Puoi iniziare con l’Archetipo in diversi modi.

Come utilizzare l’archetipo

Il primo passaggio utilizzando l’archetipo è la creazione di un progetto, che genera i moduli in una struttura di file locale. Come parte della creazione del progetto, è possibile definire una serie di proprietà del progetto, come, ad esempio, nome, versione, abilitare diverse opzioni e così via.

SUGGERIMENTO

Ogni volta che crei l’archetipo, questo genera anche una serie di riferimenti, fornendo i dettagli tecnici e l’utilizzo di ciascun modulo come nel collegamento qui sotto.

Lo sviluppo del progetto con Maven crea gli artefatti (pacchetti e bundle OSGi) che possono essere distribuiti ad AEM. Ulteriori comandi e profili Maven possono essere utilizzati per distribuire gli artefatti del progetto s un’istanza di AEM.

Informazioni sull’utilizzo dell’archetipo

L’archetipo è costituito da moduli, tutti creati automaticamente quando si utilizza l’archetipo.

  • core è un bundle Java contenente tutte le funzionalità core come servizi OSGi, ascoltatori e schedulatori nonché il codice Java relativo ai componenti, come servlet e filtri di richiesta.
  • it.test sono test di integrazione basati su Java.
  • ui.apps contiene le parti /apps e /etc del progetto, ad esempio clientlib JS e CSS, componenti e modelli.
  • ui.content contiene esempi di contenuto che utilizzano i componenti del modulo ui.apps.
  • ui.config contiene le configurazioni OSGi specifiche per la modalità di esecuzione del progetto.
  • ui.frontend.general contiene gli artefatti necessari per utilizzare il modulo di sviluppo front-end generale basato su Webpack (facoltativo).
  • ui.frontend.react (facoltativo) contiene gli artefatti necessari quando si utilizza l’archetipo per creare progetti SPA basati su React (facoltativo, dipende dai parametri di build).
  • ui.frontend.angular (facoltativo) contiene gli artefatti necessari quando si utilizza l’archetipo per creare progetti SPA basati su Angular (facoltativo, dipende dai parametri di build).
  • ui.tests: contiene i test dell’interfaccia utente basati su Selenium.
  • all: è un singolo pacchetto di contenuti che incorpora tutti i moduli compilati (bundle e pacchetti di contenuti), comprese le dipendenze dei fornitori.
  • dispatcher.ams: contiene le configurazioni di base del dispatcher per i progetti AMS/on-premise (facoltativo, dipende dai parametri di build).
  • dispatcher.cloud: contiene le configurazioni di base del dispatcher per i progetti AEMaaCS (facoltativo, dipende dai parametri di build).

Organizzazione del pacchetto di contenuti

I moduli dell’archetipo rappresentati in Maven vengono distribuiti su AEM come pacchetti di contenuto che rappresentano l’applicazione, il contenuto e i bundle OSGi necessari.

POM (Project Object Model) padre

Il file pom.xml nella directory principale del progetto (<src-directory>/<project>/pom.xml) è noto come POM padre e gestisce la struttura del progetto nonché le dipendenze e alcune proprietà globali del progetto stesso.

Proprietà globali del progetto

La sezione <properties> del POM padre definisce diverse proprietà globali importanti per la distribuzione del progetto a un’istanza di AEM, come nome utente/password, nome host/porta, ecc.

Queste proprietà sono configurate per la distribuzione a un’istanza di AEM locale, in quanto si tratta dello sviluppo più comune utilizzato dagli sviluppatori. Tieni presente che esistono anche proprietà configurate per la distribuzione a un’istanza Autore e un’istanza Publish. Qui vengono impostate anche le credenziali per l’autenticazione nell’istanza di AEM. Vengono utilizzate le credenziali admin:admin predefinite.

Queste proprietà sono configurate in modo che possano essere ignorate durante la distribuzione in ambienti di livello superiore. In questo modo, i file POM non devono essere modificati, ma le variabili come aem.host e sling.password possono essere ignorate inserendo argomenti nella riga di comando:

mvn -PautoInstallPackage clean install -Daem.host=production.hostname -Dsling.password=productionpasswd

Struttura modulare

La sezione <modules> del POM padre definisce i moduli che verranno sviluppati nel progetto. Per impostazione predefinita, il progetto genera i moduli standard precedentemente definiti. Man mano che un progetto evolve, si possono sempre aggiungere altri moduli.

Dipendenze

La sezione <dependencyManagement> del POM padre definisce tutte le dipendenze e le versioni delle API utilizzate nel progetto. Le versioni devono essere gestite nel POM principale. I sottomoduli non devono includere informazioni sulle versioni.

Uber-Jar

Una delle dipendenze chiave è AEM Java API Jar. Ciò includerà tutte le API di AEM con un’unica voce di dipendenza per la versione di AEM.

NOTA

Come best practice, aggiorna la versione di uber-jar in modo che corrisponda alla versione di destinazione di AEM. Ad esempio, se prevedi di distribuire su AEM 6.5, devi aggiornare la versione di uber-jar alla 6.5.X, in cui X è il service pack più recente.

Componenti core

L’archetipo ovviamente utilizza i componenti core. Pertanto, per sfruttare i componenti core in tutte le implementazioni, è consigliabile includerli come parte del progetto Maven.

I core.wcm.components.examples sono un set di esempi di pagine che illustrano esempi di Componenti core. Come best practice, quando distribuisci un progetto per la produzione, dovresti rimuovere questa dipendenza e l’inclusione di pacchetti secondari.

NOTA

I componenti core e l’archetipo vengono mantenuti come progetti GitHub separati e come tali le loro versioni differiscono.

Ogni versione di archetipo utilizzerà l’ultima versione dei componenti core disponibile al momento della versione. Tuttavia, potrebbe essere utile aggiornare manualmente la dipendenza dai componenti core.

Test

Il progetto contiene tre livelli di test e, poiché esistono diversi tipi di test, essi vengono eseguiti in modi diversi o in posizioni diverse.

  • Test di unità: test di unità classici del codice contenuto nel bundle
  • Test di integrazione: test di integrazione lato server che vengono eseguiti come test unità in ambiente AEM, ad esempio sul server AEM.
  • Test dell’interfaccia utente: test lato browser basati su Selenium per verificare il comportamento lato browser

In questa pagina