Struttura dei progetti AEM

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.

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 nell'archivio, /content, /conf, /var, /etc, /oak:index, /system, /tmp, ecc. sono tutti mutabile aree, ovvero possono essere modificate in fase di runtime.

Indici Oak

Indici Oak (/oak:index) sono gestite 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 /oak:index Le configurazioni fanno parte del pacchetto di codice e non fanno parte del pacchetto di contenuti come descritto di seguito.

Struttura del pacchetto consigliata

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.

• La ui.apps il pacchetto contiene tutto il codice da distribuire e distribuisce solo in /apps. Elementi comuni ui.apps Il pacchetto include, ma non è limitato a:

  • Definizioni dei componenti e HTL script
    • /apps/my-app/components
  • JavaScript e CSS (tramite Librerie client)
    • /apps/my-app/clientlibs
  • Sovrapposizioni di /libs
    • /apps/cq, /apps/dam/, ecc.
  • Configurazioni in base al contesto di fallback
    • /apps/settings
  • ACL (autorizzazioni)
    • Qualsiasi rep:policy per qualsiasi percorso /apps
  • Script raggruppati precompilati

Pacchetti di contenuti

• La ui.content il pacchetto contiene tutto il contenuto e la configurazione. Il pacchetto di contenuti contiene tutte le definizioni dei nodi non incluse nella ui.apps o ui.config pacchetti, o in altre parole, qualsiasi cosa non in /apps o /oak:index. Elementi comuni ui.content Il pacchetto include, ma non è limitato a:
  • 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

• La all pacchetto contenitore che include SOLO gli artefatti distribuibili, il file Jar del bundle OSGI, ui.apps, ui.config e ui.content pacchetti come incorporamenti. La all il pacchetto non deve avere qualsiasi contenuto o codice di per sé, ma delegare tutta la distribuzione all'archivio ai relativi pacchetti secondari o file Jar del bundle OSGi.

  I pacchetti sono ora inclusi utilizzando Maven Configurazione incorporamenti del plug-in Maven del pacchetto FileVault, anziché <subPackages> configurazione.

  Per implementazioni Experienci Manager complesse, può essere utile creare più ui.apps, ui.config e ui.content progetti/pacchetti 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 all pacchetto di contenuto del contenitore.

  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 da entrambi sito A e 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

• La ui.config pacchetto contiene tutto Configurazioni OSGi:

  • È stato preso in considerazione il codice e appartiene ai bundle OSGi ma non contiene nodi di contenuto regolari. Così è contrassegnato come un pacchetto contenitore
  • 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
    • Inizio repository è il metodo consigliato per distribuire (variabile) contenuti che fanno parte logica dell’applicazione AEM. Le configurazioni Repo Init OSGi devono essere posizionate nelle posizioni appropriate config.<runmode> come descritto in precedenza e può essere utilizzato per definire:
      • Strutture di contenuto di base
      • Utenti
      • Utenti del servizio
      • Gruppi
      • ACL (autorizzazioni)

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

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 tipi di pacchetto consentono di chiarire lo scopo e la distribuzione di un pacchetto.

• I pacchetti contenitore devono impostare i relativi packageType a container. I pacchetti contenitore non devono contenere nodi regolari. Sono consentiti solo bundle, configurazioni e pacchetti secondari OSGi. I contenitori in AEM as a Cloud Service non possono utilizzare installare gli hook.
• I pacchetti di codice (immutabili) devono impostare i rispettivi packageType a application.
• I pacchetti di contenuto (mutabili) devono impostare i relativi packageType a content.

Per ulteriori informazioni consulta FileVault Apache Jackrabbit - Documentazione del plugin Maven, Tipi di pacchetti Apache Jackrabbite Frammento di configurazione FileVault Maven sotto.

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

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 ui.config possono e devono essere utilizzati come script per definire le seguenti strutture mutabili:

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

Gli script Repo Init sono memorizzati come scripts voci RepositoryInitializer Le configurazioni di fabbrica OSGi, e quindi, possono essere eseguite in modo implicito in 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 .config Formato di configurazione OSGi in quanto supportano più righe, il che costituisce un'eccezione alle best practice relative all'utilizzo .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.

Il vocabolario completo per gli script Repo Init è disponibile sul sito Documentazione di Apache Sling Repo Init.

Pacchetto struttura archivio

I pacchetti di codice richiedono la configurazione del plug-in FileVault Maven per fare riferimento a un <repositoryStructurePackage> che applica la correttezza delle dipendenze strutturali (per garantire che un pacchetto di codice non si installi su un altro). È possibile crea un pacchetto personalizzato per la struttura dell’archivio 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, vedi Sviluppare un pacchetto con la struttura dell’archivio.

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

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 il plug-in FileVault Maven <embeddeds> configurazione. Tieni presente che <subPackages> la configurazione 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

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

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

Scomposizione della struttura delle cartelle:

• Cartella di primo livello devono /apps.

• La cartella di secondo livello rappresenta l'applicazione con -packages post-fisso al 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 application cartella contiene pacchetti di codice
  • La content la cartella contiene pacchetti di contenuto
  • La container cartella contiene qualsiasi pacchetti applicativi aggiuntivi che potrebbe essere incluso nell'applicazione AEM.
    Questo nome della cartella corrisponde al 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 a only installa su AEM pubblica 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'autore AEM che per AEM pubblicare
  • 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 AEM creazione che per AEM pubblicazione
  • ui.content.publish incorporato in /apps/my-app-packages/content/install.publish distribuisce contenuto e configurazione solo AEM pubblicazione

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 del progetto contenitore filter.xml per garantire che i pacchetti incorporati siano inclusi nel pacchetto contenitore quando generato.

Aggiungi semplicemente il <filter root="/apps/<my-app>-packages"/> voci per qualsiasi cartella di secondo livello che contiene pacchetti secondari da distribuire.

Incorporazione di pacchetti di terze parti

Tutti i pacchetti devono essere disponibili tramite Archivio degli artefatti Maven pubblico di Adobe o un archivio di artefatti Maven di terze parti accessibile al pubblico.

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.

Le applicazioni/i connettori di terze parti devono essere incorporati utilizzando all come contenitore nel 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) è sopra descritto.

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 è costituita dai pacchetti contenenti contenuto variabile (ui.content) deve 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), only contiene i bundle OSGi. In tal caso, nessun pacchetto AEM deve dichiarare una dipendenza da esso. Questo perché i pacchetti di codice non possono essere modificati only contenenti bundle OSGi non sono registrati con AEM Gestione pacchetti, e quindi, qualsiasi pacchetto AEM a seconda di esso avrà una dipendenza non soddisfatta e non riuscirà ad installarsi.

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

Dipendenze dei pacchetti di distribuzione semplici

Il caso semplice imposta la variabile ui.content pacchetto di contenuti modificabili a seconda del ui.apps pacchetto di codice immutabile.

• 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 di cui al presente articolo sono completamente compatibile AEM di sviluppo locale.

Snippet XML POM

I seguenti sono Maven pom.xml snippet di configurazione che possono essere aggiunti ai progetti Maven per allinearli ai consigli 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 contenitore all/pom.xml progetto non dichiarare <packageType>.

Tipi di pacchetti di codice (immutabile)

I pacchetti di codice devono impostare le packageType a application.

In ui.apps/pom.xml, <packageType>application</packageType> le direttive di configurazione della build filevault-package-maven-plugin la dichiarazione del 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.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 packageType a content.

In ui.content/pom.xml, <packageType>content</packageType> direttiva sulla configurazione della build filevault-package-maven-plugin la dichiarazione del 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>
    ...

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 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 contenenti gli script Repo Init sono definiti nella sezione RepositoryInitializer Configurazione di fabbrica OSGi tramite scripts proprietà. Tieni presente che, poiché questi script sono definiti nelle configurazioni OSGi, possono essere facilmente delimitati dalla modalità di esecuzione utilizzando il consueto ../config.<runmode> semantica delle cartelle.

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

/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 scripts La proprietà OSGi contiene direttive definite dal Lingua Repo Init di Apache Sling.

Pacchetto struttura archivio

In ui.apps/pom.xml e 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. È possibile crea un pacchetto personalizzato per la struttura dell’archivio 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 quanto segue <embeddeds> direttiva filevault-package-maven-plugin dichiarazione del plugin. Ricorda, non utilizza <subPackages> , in quanto includerà i pacchetti secondari in /etc/packages piuttosto che /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 multipli /apps/*-packages sono utilizzati nei target incorporati, quindi tutti devono essere enumerati qui.

Repository Maven di terze parti

Nel progetto del reattore pom.xml, aggiungi eventuali direttive di repository Maven pubbliche di terze parti necessarie. Il pieno <repository> la configurazione deve essere disponibile dal provider dell'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 quanto segue <dependencies> direttiva filevault-package-maven-plugin dichiarazione del 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 le 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>

Risorse aggiuntive

• Gestione dei pacchetti con Maven
• Plug-in Maven pacchetto di contenuti FileVault