Struttura dei progetti AEM

SUGGERIMENTO

Acquisisci familiarità con l'utilizzo di base di AEM Project Archetype e con il FileVault Content Maven Plug-in in quanto questo articolo si basa su questi insegnamenti e concetti.

Il presente articolo illustra le modifiche necessarie affinché i progetti Adobe Experience Manager Maven siano AEM compatibili con l’as a Cloud Service, garantendo che rispettino la suddivisione dei contenuti mutabili e immutabili, che le dipendenze siano stabilite per creare distribuzioni deterministiche non in conflitto e che siano inserite in una struttura distribuibile.

AEM implementazioni di applicazioni devono essere costituite da un singolo pacchetto AEM. Questo pacchetto deve a sua volta contenere pacchetti secondari che comprendono tutto ciò che l’applicazione deve funzionare, compresi il codice, la configurazione ed eventuali contenuti 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.

SUGGERIMENTO

Le configurazioni descritte in questo documento sono fornite da AEM Project Maven Archetype 24 o versioni successive.

Aree variabili e immutabili dell'archivio

/apps e /libssono 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.

Tutto il resto nel repository, /content, /conf, /var, /etc, /oak:index, /system, /tmp, ecc. sono tutte le aree mutabili, il che significa che possono essere modificate in fase di runtime.

AVVERTENZA

Come nelle versioni precedenti di AEM, /libs non deve essere modificato. Solo AEM codice prodotto può essere distribuito su /libs.

Indici Oak

Gli indici Oak (/oak:index) sono gestiti in modo specifico dal processo di distribuzione as a Cloud Service AEM. Questo perché Cloud Manager deve attendere fino a quando non viene distribuito alcun nuovo indice e completamente reindicizzato prima di passare alla nuova immagine del codice.

Per questo motivo, anche se gli indici Oak sono modificabili in fase di esecuzione, devono essere distribuiti come codice in modo che possano essere installati prima che vengano installati pacchetti mutabili. Pertanto le configurazioni /oak:index fanno parte del pacchetto di codice e non del pacchetto di contenuti come descritto di seguito.

SUGGERIMENTO

Per ulteriori dettagli sull'indicizzazione in AEM as a Cloud Service, consulta il documento Ricerca e indicizzazione dei contenuti.

Experience Manager struttura del pacchetto di progetto

Questo diagramma fornisce una panoramica della struttura di progetto consigliata e degli artefatti di distribuzione dei pacchetti.

La struttura di distribuzione dell'applicazione consigliata è la seguente:

Pacchetti di codice / Bundle OSGi

  • Il file Jar del bundle OSGi viene generato e incorporato direttamente in tutto il progetto.

  • Il pacchetto ui.apps contiene tutto il codice da distribuire e viene distribuito solo su /apps. Gli elementi comuni del pacchetto ui.apps includono, tra l'altro:

  • Il pacchetto ui.config contiene tutte le configurazioni OSGi:

    • Cartella organizzativa contenente definizioni di configurazione OSGi specifiche della modalità di esecuzione
      • /apps/my-app/osgiconfig
    • Cartella di configurazione OSGi comune contenente configurazioni OSGi predefinite che si applicano a tutte le destinazioni di distribuzione as a Cloud Service AEM target
      • /apps/my-app/osgiconfig/config
    • Cartelle di configurazione OSGi specifiche per la modalità di esecuzione che contengono configurazioni OSGi predefinite applicabili a tutte le destinazioni di distribuzione as a Cloud Service AEM target
      • /apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
    • Script di configurazione OSGi di Repo Init
      • Repo Initis è il modo consigliato per distribuire contenuto (mutabile) che fa parte logicamente dell'applicazione AEM. Le configurazioni Repo Init OSGi devono trovarsi nella cartella config.<runmode> appropriata come descritto sopra e devono essere utilizzate per definire:
        • Strutture di contenuto di base
        • Utenti
        • Utenti del servizio
        • Gruppi
        • ACL (autorizzazioni)
NOTA

Lo stesso codice deve essere distribuito a tutti gli ambienti. Ciò è necessario per garantire un livello di convalide di affidabilità anche nell’ambiente stage. Per ulteriori informazioni, consulta la sezione sulle modalità di esecuzione.

Pacchetti di contenuti

  • Il pacchetto ui.content contiene tutto il contenuto e la configurazione. Il pacchetto di contenuti contiene tutte le definizioni dei nodi che non sono presenti nei pacchetti ui.apps o ui.config o in altre parole, in elementi diversi da /apps o /oak:index. Gli elementi comuni del pacchetto ui.content includono, tra l'altro:
    • Configurazioni in base al contesto
      • /conf
    • Strutture di contenuto complesse e necessarie (ad esempio Compilazione del contenuto che si basa e si estende oltre le strutture di contenuto della linea di base definite in Repo Init.)
      • /content, /content/dam, ecc.
    • Tassonomie di assegnazione tag gestite
      • /content/cq:tags
    • Nodi legacy ecc (Idealmente, esegui la migrazione a posizioni diverse/ecc.)
      • /etc

Pacchetti contenitore

  • Il pacchetto all è un pacchetto contenitore che include SOLO gli artefatti distribuibili, il file Jar del bundle OSGI, ui.apps, ui.config e i pacchetti ui.content come incorporamenti. Il pacchetto all non deve avere alcun contenuto o codice proprio, ma deve delegare tutta la distribuzione all'archivio ai relativi pacchetti secondari o file Jar del bundle OSGi.

    I pacchetti sono ora inclusi utilizzando la configurazione incorporata del plug-in Maven FileVault Package Maven anziché la configurazione <subPackages>.

    Per implementazioni Experienci Manager complesse, può essere opportuno creare più progetti/pacchetti ui.apps, ui.config e ui.content che rappresentano siti o tenant specifici in AEM. In questo caso, assicurati che la divisione tra contenuto variabile e immutabile sia rispettata e che i pacchetti di contenuto richiesti e i file Jar del bundle OSGi siano incorporati come pacchetti secondari nel pacchetto di contenuto contenitore all .

    Ad esempio, una struttura complessa dei pacchetti di contenuto di distribuzione potrebbe avere un aspetto simile al seguente:

    • all il pacchetto di contenuti incorpora i seguenti pacchetti, per creare un singolo artefatto di distribuzione
      • common.ui.apps distribuisce il codice richiesto sia dal ​sito A che dal sito B
      • site-a.core Jar del bundle OSGi richiesto dal sito A
      • site-a.ui.apps distribuisce il codice richiesto dal sito A
      • site-a.ui.config distribuisce le configurazioni OSGi richieste dal sito A
      • site-a.ui.content distribuisce il contenuto e la configurazione richiesti dal sito A
      • site-b.core Jar del bundle OSGi richiesto dal sito B
      • site-b.ui.apps distribuisce il codice richiesto dal sito B
      • site-b.ui.config distribuisce le configurazioni OSGi richieste dal sito B
      • site-b.ui.content distribuisce il contenuto e la configurazione richiesti dal sito B

Pacchetti applicativi aggiuntivi

Se la distribuzione AEM utilizza altri progetti AEM, che sono essi stessi costituiti da pacchetti di codice e contenuto propri, i relativi pacchetti contenitore devono essere incorporati nel pacchetto all del progetto.

Ad esempio, un progetto AEM che include 2 applicazioni AEM fornitori potrebbe avere un aspetto simile al seguente:

  • all il pacchetto di contenuti incorpora i seguenti pacchetti, per creare un singolo artefatto di distribuzione
    • core Jar del bundle OSGi richiesto dall'applicazione AEM
    • ui.apps distribuisce il codice richiesto dall'applicazione AEM
    • ui.config distribuisce le configurazioni OSGi richieste dall'applicazione AEM
    • ui.content distribuisce il contenuto e la configurazione richiesti dall'applicazione AEM
    • vendor-x.all distribuisce tutto (codice e contenuto) richiesto dall'applicazione X del fornitore
    • vendor-y.all distribuisce tutti gli elementi (codice e contenuto) richiesti dall'applicazione Y del fornitore

Tipi di pacchetti

I pacchetti devono essere contrassegnati con il tipo di pacchetto dichiarato.

  • I pacchetti contenitore devono impostare i rispettivi packageType su container. I pacchetti contenitore non devono contenere direttamente i bundle OSGi, le configurazioni OSGi e non possono utilizzare gli hook di installazione.
  • I pacchetti di codice (immutabili) devono impostare i rispettivi packageType su application.
  • I pacchetti di contenuto (modificabili) devono impostare i rispettivi packageType su content.

Per ulteriori informazioni, consulta Apache Jackrabbit FileVault - Package Maven Plugin documentation e il frammento di configurazione FileVault Maven qui sotto.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Contrassegno 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>.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Inizio repository

Repo Init fornisce istruzioni, o script, che definiscono strutture JCR, che vanno dalle strutture di nodi comuni come strutture di cartelle, agli utenti, utente di servizio, gruppi e definizione ACL.

I vantaggi principali di Repo Init sono che dispongono di autorizzazioni implicite per eseguire tutte le azioni definite dai loro script e vengono richiamati all'inizio del ciclo di vita dell'implementazione, assicurando che tutte le strutture JCR necessarie esistano dal codice temporale.

Mentre gli script Repo Init stessi vivono nel progetto ui.config come script, possono e devono essere utilizzati per definire le seguenti strutture modificabili:

  • Strutture di contenuto di base
  • Utenti del servizio
  • Utenti
  • Gruppi
  • ACL

Gli script Repo Init vengono memorizzati come voci scripts di RepositoryInitializer configurazioni di fabbrica OSGi e possono quindi essere implicitamente indirizzati dalla modalità di esecuzione, consentendo differenze tra gli script Repo Init di AEM Author e AEM Publish Services o anche tra ambienti (Dev, Stage e Prod).

Le configurazioni OSGi di Repo Init sono meglio scritte nel formato di configurazione .config OSGi in quanto supportano le più righe, il che rappresenta un'eccezione alle best practice relative all'utilizzo di .cfg.json per definire le configurazioni OSGi.

Tieni presente che quando definisci Utenti e Gruppi, solo i gruppi vengono considerati parte dell’applicazione e che la relativa funzione deve essere integrata in questo campo. Gli utenti e i gruppi dell'organizzazione devono ancora essere definiti in fase di runtime 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 raggruppamento è puramente organizzativo, come "Wendy's Team" e "Sean's Team", questi sono definiti al meglio e gestiti in fase di runtime in AEM.

SUGGERIMENTO

Gli script Repo Init devono essere definiti nel campo inline scripts e la configurazione references non funzionerà.

Il vocabolario completo per gli script Repo Init è disponibile nella documentazione Apache Sling Repo Init.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Repo Init Snippets di seguito.

Pacchetto struttura archivio

I pacchetti di codice richiedono la configurazione del plug-in FileVault Maven per fare riferimento a un <repositoryStructurePackage> che impone la correttezza delle dipendenze strutturali (per garantire che un pacchetto di codice non si installi su un altro). Puoi creare un pacchetto di struttura dell'archivio 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 della struttura dell'archivio per l'applicazione, consulta Sviluppare un pacchetto della struttura dell'archivio.

Tieni presente che i pacchetti di contenuto (<packageType>content</packageType>) non richiedono questo pacchetto di struttura dell’archivio.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Incorporazione di pacchetti secondari nel pacchetto contenitore

I pacchetti di contenuto o codice vengono inseriti in una cartella speciale "side-car" e possono essere destinati all'installazione su AEM autore, AEM pubblicazione o entrambi, utilizzando la configurazione <embeddeds> del plug-in FileVault Maven. Tieni presente che la configurazione <subPackages> non deve essere utilizzata.

I casi d’uso comuni includono:

  • ACL/autorizzazioni che differiscono tra gli utenti AEM autore e AEM utenti di pubblicazione
  • Configurazioni utilizzate per supportare attività solo su AEM autore
  • Codice come le integrazioni con i sistemi di back-office, necessario solo per l'esecuzione su AEM autore

Incorporazione di pacchetti

Per eseguire il targeting AEM autore, AEM pubblicazione o entrambi, il pacchetto è incorporato nel pacchetto contenitore all in una cartella-posizione speciale, nel seguente formato:

/apps/<app-name>-packages/(content|application|container)/install(.author|.publish)?

Scomposizione della struttura delle cartelle:

  • 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 solo una singola 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
    AVVERTENZA

    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, content oppure container

    • La cartella application contiene pacchetti di codice
    • La cartella content contiene pacchetti di contenuto
    • La cartella container contiene tutti i pacchetti applicativi aggiuntivi che possono essere inclusi dall'applicazione AEM.
      Questo nome della cartella corrisponde 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 pubblicazione Nota 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’authoring e la pubblicazione può avere un aspetto simile al seguente:

  • all Il pacchetto contenitore incorpora i seguenti pacchetti, per creare un singolo artefatto di distribuzione
    • ui.apps incorporato in /apps/my-app-packages/application/install distribuisce il codice sia per l’authoring AEM che per la pubblicazione AEM
    • 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 contenuti e configurazioni sia per l’authoring AEM che per la pubblicazione AEM
    • ui.content.publish incorporato in /apps/my-app-packages/content/install.publish distribuisce contenuto e configurazione per AEM solo pubblicazione
SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Definizione del filtro del pacchetto contenitore

A causa dell’incorporazione del codice e dei pacchetti secondari del contenuto nel pacchetto contenitore, i percorsi di destinazione incorporati devono essere aggiunti al filter.xml del progetto contenitore per garantire che i pacchetti incorporati siano inclusi nel pacchetto contenitore quando generato.

È sufficiente aggiungere le voci <filter root="/apps/<my-app>-packages"/> per tutte le cartelle di secondo livello che contengono pacchetti secondari da distribuire.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Incorporazione di pacchetti di terze parti

Tutti i pacchetti devono essere disponibili tramite l’ archivio degli artefatti Maven pubblico di Adobe o un archivio degli artefatti Maven di terze parti accessibile al pubblico 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.

I connettori/applicazioni di terze parti devono essere incorporati utilizzando il relativo pacchetto all come contenitore nel pacchetto contenitore del progetto (all).

L’aggiunta delle dipendenze Maven segue le pratiche Maven standard e l’incorporazione di artefatti di terze parti (pacchetti di codice e contenuto) è descritta sopra.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

Dipendenze del pacchetto tra ui.apps da ui.content Pacchetti

Al fine di garantire la corretta installazione dei pacchetti, si raccomanda di stabilire dipendenze tra i pacchetti.

La regola generale è che i pacchetti contenenti contenuto variabile (ui.content) devono dipendere dal codice immutabile (ui.apps) che supporta il rendering e l’utilizzo del contenuto modificabile.

Un'eccezione notevole a questa regola generale è se il pacchetto di codice immutabile (ui.apps o qualsiasi altro), solo contiene i bundle OSGi. In tal caso, nessun pacchetto AEM deve dichiarare una dipendenza da esso. Questo perché i pacchetti di codice immutabili solo contenenti bundle 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 installarlo.

SUGGERIMENTO

Per un frammento completo, consulta la sezione Frammenti XML POM di seguito.

I pattern comuni per le dipendenze dei pacchetti di contenuto sono:

Dipendenze dei pacchetti di distribuzione semplici

Il caso semplice imposta il pacchetto di contenuto variabile ui.content in modo che dipenda dal pacchetto di codice immutabile ui.apps .

  • all non ha dipendenze
    • ui.apps non ha dipendenze
    • ui.content dipende da ui.apps

Dipendenze del pacchetto di distribuzione complesse

Le implementazioni complesse si espandono in base al caso semplice e impostano le dipendenze tra il contenuto variabile corrispondente e i pacchetti di codice immutabili. Se necessario, le dipendenze possono essere stabilite anche tra pacchetti di codice immutabili.

  • all non ha dipendenze
    • common.ui.apps.common non ha dipendenze
    • site-a.ui.apps dipende da common.ui.apps
    • site-a.ui.content dipende da site-a.ui.apps
    • site-b.ui.apps dipende da common.ui.apps
    • site-b.ui.content dipende da site-b.ui.apps

Sviluppo locale e distribuzione

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

Snippet XML POM

Di seguito sono riportati i snippet di configurazione Maven pom.xml che possono essere aggiunti ai progetti Maven per allinearli alle 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 progetto contenitore all/pom.xml non dichiara un <packageType>.

Tipi di pacchetti di codice (immutabile)

I pacchetti di codice devono impostare i rispettivi packageType su application.

Nelle ui.apps/pom.xml, le direttive di configurazione della build <packageType>application</packageType> della dichiarazione del plug-in filevault-package-maven-plugin 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 contenuto (variabile)

I pacchetti di contenuto devono impostare i rispettivi packageType su content.

Nella ui.content/pom.xml, la direttiva di configurazione della build <packageType>content</packageType> della dichiarazione del plug-in filevault-package-maven-plugin dichiara 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.content</name>
        <packageType>content</packageType>
        <accessControlHandling>merge</accessControlHandling>
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Contrassegno dei pacchetti per l’implementazione 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. Il pacchetto contenitore (all) deve essere il singolo pacchetto distribuito tramite Cloud Manager, che a sua volta incorpora tutti i pacchetti di codice e contenuto richiesti.

...
<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>
    ...

Inizio repository

Gli script Repo Init che contengono gli script Repo Init sono definiti nella configurazione di fabbrica RepositoryInitializer OSGi tramite la proprietà scripts . Tieni presente che questi script definiti nelle configurazioni OSGi, possono essere facilmente delimitati dalla modalità di esecuzione utilizzando la semantica di cartelle ../config.<runmode> usuale.

Poiché gli script sono in genere dichiarazioni su più righe, è più facile definirli nel file .config rispetto al formato .cfg.json basato su JSON.

/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 direttive definite dalla lingua Repo Init di Apache Sling.

Pacchetto struttura archivio

Nel ui.apps/pom.xml e in qualsiasi altro pom.xml che dichiara un pacchetto di codice (<packageType>application</packageType>), aggiungi la seguente configurazione del pacchetto della struttura dell'archivio al plug-in FileVault Maven. Puoi creare un pacchetto di struttura dell'archivio 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, aggiungi le seguenti <embeddeds> direttive alla dichiarazione del plug-in filevault-package-maven-plugin. Ricorda che non utilizza la configurazione <subPackages>, in quanto includerà i pacchetti secondari in /etc/packages anziché /apps/my-app-packages/<application|content|container>/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 -->

          <!-- OSGi Bundle Jar file that deploys to BOTH AEM Author and AEM Publish -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.core</artifactId>
              <type>jar</type>
              <target>/apps/my-app-packages/application/install</target>
          </embedded>

          <!-- 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>

           <!-- OSGi configuration code package that deploys to BOTH AEM Author and AEM Publish -->
          <embedded>
              <groupId>${project.groupId}</groupId>
              <artifactId>my-app.ui.config</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  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Definizione del filtro del 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 vengono utilizzati più /apps/*-packages, è necessario enumerarli tutti qui.

Repository Maven di terze parti

AVVERTENZA

L’aggiunta di più archivi Maven può estendere i tempi di creazione Maven, in quanto ulteriori archivi Maven saranno controllati per verificare la presenza di dipendenze.

Nel progetto di reattore pom.xml, aggiungi tutte le necessarie direttive di repository Maven pubbliche di terze parti. La configurazione <repository> completa deve essere disponibile dal provider di archivio 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 da ui.content Pacchetti

In ui.content/pom.xml, aggiungi le seguenti <dependencies> direttive alla dichiarazione del plug-in filevault-package-maven-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 aggiungi il plug-in maven-clean-plugin 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>

Risorse aggiuntive

In questa pagina