Show Menu
ARGOMENTI×

Struttura dei progetti AEM

Acquisisci familiarità con l'utilizzo di base AEM Project Archetype e con il plug-in vlt-mavenplugin.html FileVault Content Maven, man mano che questo articolo si basa su tali conoscenze e concetti.
Il presente articolo illustra le modifiche necessarie ai progetti Adobe Experience Manager Maven per essere AEM Cloud Service compatibile, garantendo che rispettino la suddivisione dei contenuti mutabili e immutabili; che siano stabilite dipendenze necessarie per creare distribuzioni deterministiche non conflittuali; e che siano raggruppati in una struttura distribuibile.
AEM distribuzioni dell'applicazione devono essere composte da un unico pacchetto AEM. Questo pacchetto deve contenere a sua volta sottopacchetti che comprendono tutto ciò che l'applicazione richiede per funzionare, compreso il codice, la configurazione e qualsiasi contenuto di base di supporto.
AEM richiede una separazione di contenuto e codice , il che significa che un singolo pacchetto di contenuti non può essere distribuito sia su /apps che su aree scrivibili di runtime dell’archivio (ad esempio /content , /conf , /home o tutto il resto fuorché /apps ). Al contrario, l’applicazione deve separare codice e contenuto in pacchetti discreti da distribuire in AEM.
La struttura del pacchetto descritta in questo documento è compatibile sia con le distribuzioni di sviluppo locali che con le distribuzioni di AEM Cloud Service.
Le configurazioni descritte in questo documento sono fornite da AEM Project Maven Archetype 21 o successivo .

Aree variabile e immutabili del repository

/apps e /libs sono considerate aree immutabili di AEM poiché non possono essere modificate (create, aggiornate, eliminate) dopo l’avvio di AEM (ad es. in fase di runtime). Eventuali tentativi di modifica di un’area immutabile in fase di runtime avranno esito negativo.
Everything else in the repository, /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.
Come nelle versioni precedenti di AEM, non /libs deve essere modificato. Solo AEM codice prodotto può essere distribuito a /libs .

Indici Oak

Gli indici Oak ( /oak:index ) sono gestiti specificamente dal processo di distribuzione di AEM Cloud Services. Questo perché Cloud Manager deve aspettare che un nuovo indice venga distribuito e ricollegato completamente prima di passare alla nuova immagine del codice.
Per questo motivo, sebbene gli indici Oak siano modificabili in fase di esecuzione, devono essere distribuiti come codice in modo che possano essere installati prima che siano installati pacchetti modificabili. Di conseguenza, /oak:index le configurazioni fanno parte del pacchetto di codice e non del pacchetto di contenuti come descritto di seguito.
Per ulteriori dettagli sull'indicizzazione in AEM come Cloud Service, consultare il documento Content Search and Indexing (Ricerca e indicizzazione del contenuto).

Tipi di pacchetti

I pacchetti devono essere contrassegnati con il tipo di pacchetto dichiarato.
  • I pacchetti contenitore non devono avere un packageType set.
  • I pacchetti di codice (immutabili) devono impostare packageType su application .
  • I pacchetti di contenuto (modificabili) devono impostare packageType su content .
Per ulteriori informazioni vedere Apache Jackrabbit FileVault - Package Maven Plugin documentazione e lo snippet di configurazione FileVault Maven di seguito.
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Contrassegnazione dei pacchetti per la distribuzione tramite Adobe Cloud Manager

Per impostazione predefinita, Adobe Cloud Manager raccoglie tutti i pacchetti prodotti dalla build Maven. Tuttavia, poiché il pacchetto contenitore ( all ) è l’unico artefatto di distribuzione che contiene tutti i pacchetti di codice e contenuto, è necessario assicurarsi che sia distribuito solo il pacchetto contenitore ( all ). Per questo motivo, gli altri pacchetti generati dalla build Maven devono essere contrassegnati con la configurazione FileVault Content Package Maven Plug-In di <properties><cloudManagerTarget>none</cloudManageTarget></properties> .
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Repo Init

Repo Init fornisce istruzioni, o script, che definiscono le strutture JCR, che vanno dalle strutture nodo comuni come le strutture delle cartelle, agli utenti, agli utenti del servizio, ai gruppi e alla definizione ACL.
I vantaggi principali di Repo Init sono i permessi impliciti per eseguire tutte le azioni definite dai loro script, e vengono richiamati in anticipo nel ciclo di vita della distribuzione, garantendo che tutte le strutture JCR necessarie siano presenti dal codice temporale.
Mentre gli script Repo Init stessi vivono nel ui.apps progetto come script, possono e devono essere utilizzati per definire le seguenti strutture modificabili:
  • Strutture contenuto di base
    • Examples: /content/my-app , /content/dam/my-app , /conf/my-app/settings
  • Utenti del servizio
  • Utenti
  • Gruppi
  • ACL
Gli script Repo Init sono memorizzati come scripts voci delle configurazioni di fabbrica RepositoryInitializer OSGi e possono quindi essere implicitamente indirizzati dalla modalità di esecuzione, consentendo differenze tra gli script AEM Author e AEM Publish Services'Repo Init, o anche tra Envs (Dev, Stage e Prod).
Tenete presente che quando definite Utenti e Gruppi, solo i gruppi sono considerati parte dell’applicazione e che la funzione integrata deve essere definita qui. Gli utenti e i gruppi dell'organizzazione devono essere ancora definiti in fase di esecuzione in AEM; ad esempio, se un flusso di lavoro personalizzato assegna il lavoro a un gruppo denominato, tale gruppo deve essere definito in tramite Repo Init nell'applicazione AEM, tuttavia se il gruppo è semplicemente di tipo organizzativo, come "Wendy's Team" e "Sean's Team", questi sono definiti e gestiti in fase di runtime in AEM.
Gli script Repo Init devono essere definiti nel campo in linea scripts , e la references configurazione non funzionerà.
Il vocabolario completo per gli script Repo Init è disponibile nella documentazione di Apache Sling Repo Init.
Per un frammento completo, consulta la sezione Repo Init Snippet di seguito.

Pacchetto struttura archivio

I pacchetti di codice richiedono la configurazione del plug-in FileVault Maven per fare riferimento a una configurazione <repositoryStructurePackage> che applica la correttezza delle dipendenze strutturali (per garantire che un pacchetto di codice non venga installato su un altro). Potete creare un pacchetto di struttura del repository personalizzato per il progetto .
Questa operazione è richiesta solo per i pacchetti codice, ovvero per tutti i pacchetti contrassegnati con <packageType>application</packageType> .
Per informazioni su come creare un pacchetto di struttura del repository per l'applicazione, vedere Sviluppo di un pacchetto di struttura del repository.
I pacchetti di contenuto ( <packageType>content</packageType> ) non richiedono questo pacchetto struttura archivio.
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Incorporazione di pacchetti secondari nel pacchetto contenitore

I pacchetti di contenuto o codice vengono inseriti in una speciale cartella "side-car" e possono essere installati sia AEM autore che AEM pubblicazione, o entrambi, utilizzando la <embeddeds> configurazione del plug-in FileVault Maven. Notate che la <subPackages> configurazione non deve essere utilizzata.
I casi d’uso più comuni includono:
  • ACL/autorizzazioni che differiscono tra AEM utenti autori e AEM utenti di pubblicazione
  • Configurazioni utilizzate per supportare le attività solo su AEM autore
  • Codice come le integrazioni con i sistemi di back-office, richiesto solo per l'esecuzione su AEM autore
Per eseguire il targeting AEM autore, AEM pubblicazione o per entrambi, il pacchetto viene incorporato nel pacchetto all contenitore in una cartella specifica, nel seguente formato:
/apps/<app-name>-packages/(content|application)/install(.author|.publish)?
Suddividere la struttura delle cartelle in base a:
  • La cartella di primo livello deve essere /apps .
  • La cartella di secondo livello rappresenta l’applicazione con -packages post-fisso sul nome della cartella. Spesso esiste una sola cartella di 2° livello in cui sono incorporati tutti i pacchetti secondari, tuttavia è possibile creare un numero qualsiasi di cartelle di 2° livello per rappresentare al meglio la struttura logica dell'applicazione:
    • /apps/my-app-packages
    • /apps/my-other-app-packages
    • /apps/vendor-packages
    Per convenzione, le cartelle incorporate in un pacchetto secondario sono denominate con il suffisso -packages . In questo modo, il codice di distribuzione e i pacchetti di contenuto non vengono distribuiti nelle cartelle di destinazione di qualsiasi pacchetto secondario /apps/<app-name>/... , il che provoca un comportamento di installazione distruttivo e ciclico.
  • La cartella di terzo livello deve essere application o content
    • La application cartella contiene pacchetti di codice
    • La content cartella contiene pacchetti di contenutoIl nome della cartella deve corrispondere ai tipi di pacchetto dei pacchetti che contiene.
  • La cartella di quarto livello contiene i pacchetti secondari e deve corrispondere a una delle seguenti:
    • install per effettuare l’installazione sia su AEM Author che AEM Publish
    • install.author per eseguire l’installazione solo su AEM Author
    • install.publish per eseguire l'installazione solo su AEM pubblicazioneNotate che solo install.author e install.publish sono destinazioni supportate. Altre modalità di esecuzione non sono supportate.
Ad esempio, una distribuzione che contiene AEM pacchetti specifici per l'autore e la pubblicazione potrebbe avere l'aspetto seguente:
  • all Il pacchetto contenitore incorpora i pacchetti seguenti, per creare un artefatto di distribuzione singolo
    • ui.apps incorporato in /apps/my-app-packages/application/install distribuisce il codice sia per AEM creazione che per AEM pubblicazione
    • ui.apps.author incorporato in /apps/my-app-packages/application/install.author distribuisce il codice solo AEM autore
    • ui.content incorporato in /apps/my-app-packages/content/install distribuisce il contenuto e la configurazione sia AEM creazione che AEM pubblicazione
    • ui.content.publish incorporato in /apps/my-app-packages/content/install.publish distribuisce contenuto e configurazione solo AEM pubblicazione
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Definizione filtro pacchetto contenitore

A causa dell'incorporazione del codice e dei sottopacchetti di contenuto nel pacchetto contenitore, i percorsi di destinazione incorporati devono essere aggiunti al progetto contenitore filter.xml per garantire che i pacchetti incorporati siano inclusi nel pacchetto contenitore una volta creati.
È sufficiente aggiungere le <filter root="/apps/<my-app>-packages"/> voci per qualsiasi cartella di secondo livello che contiene pacchetti secondari da distribuire.
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Incorporazione di pacchetti di terze parti

Tutti i pacchetti devono essere disponibili tramite il Adobe archivio degli artifact Maven pubblico o un archivio degli artifact di terze parti accessibile e di riferimento.
Se i pacchetti di terze parti si trovano nell’ archivio di artefatti Maven pubblico di Adobe , per consentire ad Adobe Cloud Manager di risolvere gli artefatti non è necessario effettuare nessuna ulteriore configurazione.
Se i pacchetti di terze parti si trovano in un archivio di artefatti Maven pubblico di terze parti , tale archivio deve essere registrato nel pom.xml del progetto, per poi essere incorporato seguendo il metodo descritto sopra . Se l’applicazione/connettore di terze parti richiede pacchetti di codice e di contenuto, ciascuno di essi deve essere incorporato nelle posizioni corrette del pacchetto contenitore ( all ).
L'aggiunta di dipendenze di Paradiso segue le pratiche standard di Maven, e l'incorporazione di artefatti di terze parti (pacchetti di codice e di contenuto) è descritta sopra .
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.

Dipendenze del pacchetto tra ui.apps i pacchetti ui.content dei pacchetti

Per garantire la corretta installazione dei pacchetti, si raccomanda di stabilire dipendenze tra pacchetti.
La regola generale è che i pacchetti che contengono contenuto variabile ( ui.content ) devono dipendere dal codice immutabile ( ui.apps ) che supporta il rendering e l'uso del contenuto modificabile.
Un'eccezione notevole a questa regola generale è rappresentata dal fatto che il pacchetto di codice immutabile ( ui.apps o qualsiasi altro) contenga solo pacchetti OSGi. In tal caso, nessun pacchetto AEM deve dichiarare una dipendenza da esso. Questo perché i pacchetti di codice immutabili che contengono solo pacchetti OSGi non sono registrati con AEM Package Manager, e quindi, qualsiasi pacchetto AEM a seconda di esso avrà una dipendenza non soddisfatta e non sarà possibile eseguire l'installazione.
Per un frammento completo, consulta la sezione Snippet XML POM di seguito.
I pattern comuni per le dipendenze dei pacchetti di contenuto sono:

Dipendenze semplici del pacchetto di distribuzione

Il semplice caso imposta il pacchetto di contenuti ui.content modificabile in modo che dipenda dal pacchetto di codice ui.apps immutabile.
  • all non ha dipendenze
    • ui.apps non ha dipendenze
    • ui.content dipende da ui.apps

Dipendenze complesse del pacchetto di distribuzione

Le implementazioni complesse si espandono in base al caso semplice e impostano le dipendenze tra il contenuto mutabile corrispondente e i pacchetti di codice immutabili. Se necessario, è possibile stabilire dipendenze tra pacchetti di codice immutabili.
  • all non ha dipendenze
    • ui.apps.common non ha dipendenze
    • ui.apps.site-a dipende da ui.apps.common
    • ui.content.site-a dipende da ui.apps.site-a
    • ui.apps.site-b dipende da ui.apps.common
    • ui.content.site-b dipende da ui.apps.site-b

Sviluppo locale e implementazione

Le strutture e l'organizzazione del progetto descritte in questo articolo sono pienamente compatibili con le istanze AEM di sviluppo locale.

Snippet XML POM

Di seguito sono riportati alcuni snippet di pom.xml configurazione Maven che possono essere aggiunti ai progetti Maven per allineare le raccomandazioni di cui sopra.

Tipi di pacchetti

I pacchetti di codice e di contenuto, distribuiti come pacchetti secondari, devono dichiarare un pacchetto di tipo applicazione o contenuto , a seconda di ciò che contengono.

Tipi di pacchetti contenitore

Il all/pom.xml progetto contenitore non dichiara un <packageType> .

Tipi di pacchetti di codice (immutabili)

I pacchetti di codice devono impostare packageType su application .
Nelle ui.apps/pom.xml , le direttive di configurazione della <packageType>application</packageType> build della dichiarazione del filevault-package-maven-plugin plug-in dichiarano il tipo di pacchetto.
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.jackrabbit</groupId>
      <artifactId>filevault-package-maven-plugin</artifactId>
      <extensions>true</extensions>
      <configuration>
        <group>${project.groupId}</group>
        <name>${my-app.ui.apps}</name>
        <packageType>application</packageType>
        <accessControlHandling>merge</accessControlHandling>
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Tipi di pacchetti di contenuto (variabile)

I pacchetti di contenuto devono impostare packageType su content .
Nella ui.content/pom.xml , la direttiva di configurazione della <packageType>content</packageType> build della dichiarazione del filevault-package-maven-plugin plugin dichiara il suo tipo di pacchetto.
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.jackrabbit</groupId>
      <artifactId>filevault-package-maven-plugin</artifactId>
      <extensions>true</extensions>
      <configuration>
        <group>${project.groupId}</group>
        <name>${my-app.ui.content}</name>
        <packageType>content</packageType>
        <accessControlHandling>merge</accessControlHandling>
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Contrassegnazione dei pacchetti per distribuzione di Adobe Cloud Manager

In ogni progetto che genera un pacchetto, fatta eccezione per il progetto contenitore ( all ), aggiungi <cloudManagerTarget>none</cloudManagerTarget> alla configurazione <properties> della dichiarazione del plug-in filevault-package-maven-plugin , in modo da assicurarti che non siano distribuiti da Adobe Cloud Manager. The container ( all ) package should be the singular package deployed via Cloud Manager, which in turn embeds all required code and content packages.
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.jackrabbit</groupId>
      <artifactId>filevault-package-maven-plugin</artifactId>
      <extensions>true</extensions>
      <configuration>
        ...
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Repo Init

Gli script Repo Init che contengono gli script Repo Init sono definiti nella configurazione di fabbrica RepositoryInitializer OSGi tramite la scripts proprietà. Poiché questi script sono stati definiti nelle configurazioni OSGi, possono essere facilmente individuati in modalità di esecuzione utilizzando la semantica ../config.<runmode> delle cartelle standard.
Poiché in genere gli script sono dichiarazioni su più righe, è più semplice definirle nel .config file rispetto al formato di base XML sling:OsgiConfig .
/apps/my-app/config.author/org.apache.sling.jcr.repoinit.RepositoryInitializer-author.config
scripts=["
    create service user my-data-reader-service

    set ACL on /var/my-data
        allow jcr:read for my-data-reader-service
    end

    create path (sling:Folder) /conf/my-app/settings
"]

La proprietà scripts OSGi contiene le direttive definite dalla lingua Repo Init di Apache Sling.

Pacchetto struttura archivio

In ui.apps/pom.xml e in qualsiasi altro pom.xml che dichiara un pacchetto di codice ( <packageType>application</packageType> ), aggiungete la seguente configurazione di pacchetto struttura del repository al plug-in FileVault Maven. Potete creare un pacchetto di struttura del repository personalizzato per il progetto .
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.jackrabbit</groupId>
      <artifactId>filevault-package-maven-plugin</artifactId>
      <extensions>true</extensions>
      <configuration>
        ...
        <repositoryStructurePackages>
          <repositoryStructurePackage>
              <groupId>${project.groupId}</groupId>
              <artifactId>ui.apps.structure</artifactId>
              <version>${project.version}</version>
          </repositoryStructurePackage>
        </repositoryStructurePackages>
      </configuration>
    </plugin>
    ...

Incorporazione di pacchetti secondari nel pacchetto contenitore

In all/pom.xml , aggiungete le seguenti <embeddeds> direttive alla dichiarazione del filevault-package-maven-plugin plugin. Ricordate, non utilizzate la <subPackages> configurazione, perché includerà i pacchetti secondari in /etc/packages piuttosto che /apps/my-app-packages/<application|content>/install(.author|.publish)? .
...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          <!-- Include the application's ui.apps and ui.content packages -->
          <!-- Ensure the artifactIds are correct -->

          <!-- Code package that deploys to BOTH AEM Author and AEM Publish -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.ui.apps</artifactId>
              <type>zip</type>
              <target>/apps/my-app-packages/application/install</target>
          </embedded>

          <!-- Code package that deploys ONLY to AEM Author -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.ui.apps.author</artifactId>
              <type>zip</type>
              <target>/apps/my-app-packages/application/install.author</target>
          </embedded>

          <!-- Content package that deploys to BOTH AEM Author and AEM Publish -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.ui.content</artifactId>
              <type>zip</type>
              <target>/apps/my-app-packages/content/install</target>
          </embedded>

          <!-- Content package that deploys ONLY to AEM Publish -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.ui.content.publish-only</artifactId>
              <type>zip</type>
              <target>/apps/my-app-packages/content/install.publish</target>
          </embedded>

          <!-- Include any other extra packages such as AEM WCM Core Components -->
          <embedded>
              <groupId>com.adobe.cq</groupId>
              <!-- Not to be confused; WCM Core Components' Code package's artifact is named `.content` -->
              <artifactId>core.wcm.components.content</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/application/install</target>
          </embedded>

          <embedded>
              <groupId>com.adobe.cq</groupId>
              <!-- Not to be confused; WCM Core Components' Content package's artifact is named `.conf` -->
              <artifactId>core.wcm.components.conf</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/content/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Definizione filtro pacchetto contenitore

Nel filter.xml all del progetto ( all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml ), includi tutte le cartelle -packages che contengono pacchetti secondari da distribuire:
<filter root="/apps/my-app-packages"/>

Se nelle destinazioni di incorporamento /apps/*-packages vengono utilizzati più elementi, questi devono essere elencati qui.

Repository Maven di terze parti

L'aggiunta di più repository Maven può estendere i tempi di creazione dei cibi mentre ulteriori repository Maven saranno controllati per dipendenze.
Nel progetto del reattore pom.xml , aggiungere tutte le necessarie direttive del repository di Maven pubbliche di terze parti. La <repository> configurazione completa dovrebbe essere disponibile dal provider del repository di terze parti.
<repositories>
  ...
  <repository>
      <id>3rd-party-repository</id>
      <name>Public 3rd Party Repository</name>
      <url>https://repo.3rdparty.example.com/...</url>
      <releases>
          <enabled>true</enabled>
          <updatePolicy>never</updatePolicy>
      </releases>
      <snapshots>
          <enabled>false</enabled>
      </snapshots>
  </repository>
  ...
</repositories>

Dipendenze del pacchetto tra ui.apps i pacchetti ui.content dei pacchetti

In ui.content/pom.xml , aggiungete le seguenti <dependencies> direttive alla dichiarazione del filevault-package-maven-plugin plugin.
...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <dependencies>
        <!-- Declare the content package dependency in the ui.content/pom.xml on the ui.apps project -->
        <dependency>
            <groupId${project.groupId}</groupId>
            <artifactId>my-app.ui.apps</artifactId>
            <version>${project.version}</version>
        </dependency>
      </dependencies>
    ...
  </configuration>
</plugin>
...

Pulizia della cartella di destinazione del progetto contenitore

In all/pom.xml aggiungere il maven-clean-plugin plug-in che pulirà la directory di destinazione prima delle build Maven.
<plugins>
  ...
  <plugin>
    <artifactId>maven-clean-plugin</artifactId>
    <executions>
      <execution>
        <id>auto-clean</id>
        <!-- Run at the beginning of the build rather than the default, which is after the build is done -->
        <phase>initialize</phase>
        <goals>
          <goal>clean</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  ...
</plugins>