Utilizzo di Archetipo progetto AEM using-the-archetype
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.
Guida introduttiva getting-started
L’archetipo del progetto rende facile iniziare a sviluppare in AEM. Puoi iniziare con l’Archetipo in diversi modi.
- Tutorial WKND: per un’ottima introduzione allo sviluppo in AEM, incluso il modo di utilizzare l’archetipo, consulta la Guida introduttiva ai AEM Sites: tutorial WKND per un esempio pratico che illustra come utilizzare l’archetipo per implementare un semplice progetto.
- Tutorial eventi WKND: se sei particolarmente interessato allo sviluppo di applicazioni a pagina singola (SPA) in AEM, consulta tutorial dedicato sugli eventi WKND.
- Inizia da solo!: puoi scaricare facilmente l’archetipo del progetto corrente disponibile su GitHub e creare il tuo primo progetto da solo.
Come utilizzare l’archetipo how-to-use-the-archetype
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.
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 what-you-get
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
/appse/etcdel 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).
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 parent-pom
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 global-properties
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 module-structure
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 dependencies
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 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.
X è il service pack più recente.Componenti core core-components
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.
Test testing
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