Struttura dei progetti AEM

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

Le implementazioni delle applicazioni AEM devono essere composte da un singolo pacchetto AEM. A sua volta, questo pacchetto deve contenere pacchetti secondari che comprendono tutto ciò che l’applicazione richiede per funzionare, inclusi il codice, la configurazione e qualsiasi contenuto di base di supporto.

L'AEM richiede una separazione di contenuto e codice, che significa un singolo pacchetto di contenuti non può distribuisci in entrambi /apps e aree scrivibili di runtime (ad esempio, /content, /conf, /home, o tutto ciò che non /apps) dell’archivio. 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 mutabili e immutabili dell’archivio

Il /apps e /libs aree dell'AEM prese in considerazione immutabile perché non possono essere modificate (create, aggiornate, eliminate) dopo l’avvio dell’AEM (ovvero in fase di runtime). Qualsiasi tentativo di modificare un’area immutabile in fase di runtime non riesce.

Tutto il resto nell’archivio, /content, /conf, /var, /etc, /oak:index, /system, /tmpe così via, sono tutte mutabile , ovvero possono essere modificate in fase di runtime.

Indici Oak

Indici Oak (/oak:index) sono gestite dal processo di implementazione as a Cloud Service dell'AEM. Il motivo è che Cloud Manager deve attendere che venga distribuito e completamente reindicizzato un nuovo indice prima di passare alla nuova immagine del codice.

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

Struttura consigliata dei pacchetti

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

La struttura consigliata per la distribuzione delle applicazioni è la seguente:

Pacchetti codice/Bundle OSGi

• Il file Jar del bundle OSGi viene generato e incorporato direttamente nel progetto all.

• Il ui.apps contiene tutto il codice da distribuire e distribuisce solo in /apps. Elementi comuni della ui.apps Il pacchetto include, tra l’altro:

  • 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/, e così via.
  • Configurazioni in base al contesto di fallback
    • /apps/settings
  • ACL (autorizzazioni)
    • Qualsiasi rep:policy per qualsiasi percorso in /apps
  • Script in bundle precompilati

Pacchetti di contenuti

• Il ui.content Il pacchetto contiene tutto il contenuto e la configurazione. Il pacchetto di contenuti contiene tutte le definizioni di nodi non presenti nel ui.apps o ui.config o, in altre parole, qualsiasi cosa non contenuta in /apps o /oak:index. Elementi comuni della ui.content Il pacchetto include, tra l’altro:
  • Configurazioni in base al contesto
    • /conf
  • Strutture di contenuto complesse e obbligatorie (ovvero, strutture di contenuto che si basano su ed estendono oltre le strutture di contenuto della linea di base definite in Repo Init).
    • /content, /content/dam, e così via.
  • Tassonomie di assegnazione tag gestite
    • /content/cq:tags
  • Nodi etc legacy (idealmente, esegui la migrazione di questi nodi in posizioni non etc)
    • /etc

Pacchetti contenitore

• Il all è un pacchetto contenitore che include SOLO artefatti distribuibili, il file JAR del bundle OSGI, ui.apps, ui.config, e ui.content pacchetti come incorporamenti. Il all il pacchetto non deve avere qualsiasi contenuto o codice di per sé, ma delega l’intera distribuzione all’archivio ai relativi sottopacchetti o file Jar del bundle OSGi.

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

  Per implementazioni di Experienci Manager complesse, può essere opportuno creare più ui.apps, ui.config, e ui.content progetti/pacchetti che rappresentano siti o tenant specifici in AEM. Se si adotta questo approccio, assicurati che venga rispettata la suddivisione tra contenuto mutabile e immutabile e che i pacchetti di contenuti richiesti e i file Jar del bundle OSGi vengano incorporati come pacchetti secondari nel all pacchetto di contenuti del contenitore.

  Ad esempio, una struttura complessa del pacchetto di contenuti di distribuzione potrebbe essere simile alla seguente:

  • all il pacchetto di contenuto 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 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

• Il ui.config il pacchetto contiene tutti Configurazioni OSGi:

  • Considerato codice e appartiene ai bundle OSGi, ma non contiene nodi di contenuto regolari. In questo modo viene contrassegnato come pacchetto contenitore
  • Cartella organizzativa contenente le definizioni di configurazione OSGi specifiche per la modalità di esecuzione
    • /apps/my-app/osgiconfig
  • Cartella di configurazione OSGi comune contenente le configurazioni OSGi predefinite applicabili a tutte le destinazioni di distribuzione as a Cloud Service AEM di destinazione
    • /apps/my-app/osgiconfig/config
  • Eseguire cartelle di configurazione OSGi specifiche per la modalità che contengono configurazioni OSGi predefinite applicabili a tutte le destinazioni di distribuzione as a Cloud Service da AEM di destinazione
    • /apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
  • Script di configurazione OSGi Repo iniziale
    • Repo iniziale è il metodo consigliato per distribuire il contenuto (mutabile) che fa logicamente parte dell’applicazione AEM. Le configurazioni OSGi Repo Init devono essere posizionate nel punto appropriato config.<runmode> come descritto in precedenza e può essere utilizzato per definire:
      • Strutture di contenuto della linea di base
      • Utenti
      • Utenti del servizio
      • Gruppi
      • ACL (autorizzazioni)

Pacchetti di applicazioni aggiuntivi

Se altri progetti AEM, a loro volta costituiti da codici e pacchetti di contenuti propri, vengono utilizzati dall’implementazione dell’AEM, i pacchetti contenitore devono essere incorporati nel all pacchetto.

Ad esempio, un progetto AEM che include due applicazioni AEM di fornitori diversi potrebbe essere simile al seguente:

• all il pacchetto di contenuto 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 implementa le configurazioni OSGi richieste dall’applicazione AEM
  • ui.content implementa il contenuto e la configurazione richiesti dall’applicazione AEM
  • vendor-x.all distribuisce tutto il necessario (codice e contenuto) per l’applicazione X del fornitore
  • vendor-y.all distribuisce tutto il necessario (codice e contenuto) per l’applicazione Y del fornitore

Tipi di pacchetti

I pacchetti devono essere contrassegnati con il relativo tipo di pacchetto dichiarato. I tipi di pacchetto aiutano a chiarire lo scopo e la distribuzione di un pacchetto.

• I pacchetti contenitore devono impostare i 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 essere utilizzati installare gli hook.
• I pacchetti di codice (immutabili) devono impostare i propri packageType a application.
• I pacchetti di contenuti (mutabili) devono impostare i propri packageType a content.

Per ulteriori informazioni, consulta Apache Jackrabbit FileVault - Documentazione del plug-in Package Maven, Tipi di pacchetti Apache Jackrabbite Frammento configurazione FileVault Maven di seguito.

Contrassegno dei pacchetti per la distribuzione da parte di Adobe Cloud Manager

Per impostazione predefinita, Adobe Cloud Manager raccoglie tutti i pacchetti prodotti dalla build Maven. Tuttavia, poiché il contenitore (all) è l’unico artefatto di distribuzione che contiene tutti i pacchetti di codice e contenuto, è necessario assicurarsi che solo il contenitore (all) è implementato. 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>.

Repo iniziale

Repo Init fornisce istruzioni, o script, per definire le strutture JCR, che vanno dalle strutture di nodi comuni come le strutture di cartelle a utenti, utenti del servizio, gruppi e definizioni ACL.

I vantaggi principali di Repo Init sono le autorizzazioni implicite per eseguire tutte le azioni definite dagli script. Inoltre, tali script vengono richiamati nelle prime fasi del ciclo di vita della distribuzione, garantendo che tutte le strutture JCR richieste esistano al momento dell’esecuzione del codice temporale.

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

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

Gli script di inizializzazione dell’archivio sono memorizzati come scripts voci di RepositoryInitializer Configurazioni di fabbrica OSGi. Di conseguenza, possono essere indirizzati implicitamente dalla modalità di esecuzione, consentendo differenze tra gli script di inizializzazione dell’archivio di AEM Author e AEM Publish Services oppure tra ambienti (Dev, Stage e Prod).

Le configurazioni OSGi di Repo Init vengono scritte in modo ottimale in .config Formato di configurazione OSGi in quanto supportano più righe, il che rappresenta un’eccezione alle best practice per l’utilizzo di .cfg.json per definire le configurazioni OSGi.

Quando si definiscono Utenti e Gruppi, solo i gruppi sono considerati parte dell’applicazione e sono parte integrante della sua funzione. Puoi ancora definire gli utenti e i gruppi dell’organizzazione in fase di runtime in AEM. Ad esempio, se un flusso di lavoro personalizzato assegna il lavoro a un gruppo denominato, definisci tale gruppo tramite Repo Init nell’applicazione AEM. Tuttavia, se il Raggruppamento è puramente organizzativo, come "Wendy's Team" e "Sean's Team", questi gruppi sono meglio definiti e gestiti in fase di runtime in AEM.

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

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 venga installato su un altro). È possibile creare un pacchetto con la struttura dell’archivio personalizzato per il progetto.

Solo richiesto per i pacchetti codice, ovvero tutti i pacchetti contrassegnati con <packageType>application</packageType>.

Per informazioni su come creare un pacchetto di struttura dell’archivio per l’applicazione, consulta Sviluppare un pacchetto con la struttura dell’archivio.

Pacchetti di contenuti (<packageType>content</packageType>) non richiede questo pacchetto con struttura dell’archivio.

Incorporazione di pacchetti secondari nel pacchetto contenitore

I pacchetti di contenuto o codice vengono inseriti in una speciale cartella "side-car" e possono essere destinati all’installazione su AEM Author, AEM Publish o entrambi, utilizzando il plug-in FileVault Maven <embeddeds> configurazione. Non utilizzare il <subPackages> configurazione.

I casi d’uso comuni includono:

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

Per eseguire il targeting dell’autore AEM, delle pubblicazioni AEM o di entrambi, il pacchetto è incorporato nel all pacchetto contenitore in una posizione cartella speciale, nel formato seguente:

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

Suddivisione di questa struttura di cartelle:

• Cartella di primo livello deve essere /apps.

• La cartella di secondo livello rappresenta l'applicazione con -packages dopo il nome della cartella. Spesso esiste una sola cartella di secondo livello in cui sono incorporati tutti i pacchetti secondari. Tuttavia, è possibile creare un numero qualsiasi di cartelle di secondo 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. Questa denominazione garantisce che il codice di distribuzione e i pacchetti di contenuto siano non ha distribuito le cartelle di destinazione di qualsiasi pacchetto secondario /apps/<app-name>/... che determina un comportamento distruttivo e ciclico dell'installazione.

• La cartella di terzo livello deve essere
  application, content oppure container

  • Il application la cartella contiene pacchetti di codice
  • Il content la cartella contiene i pacchetti di contenuti
  • Il container cartella contiene qualsiasi pacchetti applicativi aggiuntivi che potrebbero essere incluse nella domanda AEM.
    Questo nome di cartella corrisponde al tipi di pacchetti dei pacchetti che contiene.

• La cartella di quarto livello contiene i pacchetti secondari e deve essere una delle seguenti:

  • install per eseguire l'installazione su entrambi Pubblicazione AEM author e AEM
  • install.author in modo da installare solo sull’autore AEM
  • install.publish in modo da installare solo solo pubblicazione AEM install.author e install.publish sono destinazioni supportate. Altre modalità di esecuzione non sono supportate.

Ad esempio, una distribuzione che contiene pacchetti specifici per l’authoring e la pubblicazione di AEM 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 all’istanza di authoring AEM che a quella di pubblicazione AEM
  • ui.apps.author incorporato in /apps/my-app-packages/application/install.author distribuisce il codice solo all’autore AEM
  • ui.content incorporato in /apps/my-app-packages/content/install distribuisce contenuti e configurazione sia all’autore AEM che alla pubblicazione AEM
  • ui.content.publish incorporato in /apps/my-app-packages/content/install.publish distribuisce contenuti e configurazione solo per la pubblicazione AEM

Definizione filtro del pacchetto contenitore

A causa dell’incorporamento del codice e dei pacchetti secondari di contenuto nel pacchetto contenitore, i percorsi di destinazione incorporati devono essere aggiunti al progetto contenitore filter.xml. In questo modo i pacchetti incorporati vengono inclusi nel pacchetto contenitore quando generato.

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

Incorporazione di pacchetti di terze parti

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

Se i pacchetti di terze parti sono in Archivio di artefatti Maven pubblico di Adobe, non è necessaria alcuna ulteriore configurazione per consentire ad Adobe Cloud Manager di risolvere gli artefatti.

Se i pacchetti di terze parti si trovano in una archivio di artefatti Maven pubblico di terze parti, questo archivio deve essere registrato nel file pom.xml e incorporati 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 di dipendenze Maven segue le pratiche Maven standard e l’incorporamento di artefatti di terze parti (pacchetti di codice e contenuti) sono descritto sopra.

Dipendenze dei pacchetti tra ui.apps da ui.content Pacchetti

Per garantire la corretta installazione dei pacchetti, si consiglia di stabilire le dipendenze tra i pacchetti.

La regola generale è costituita dai pacchetti contenenti contenuto mutabile (ui.content) deve dipendere dal codice immutabile (ui.apps) che supporta il rendering e l’utilizzo del contenuto mutabile.

Un'eccezione rilevante a questa regola generale è se il pacchetto di codice immutabile (ui.apps o altro), solo contiene i bundle OSGi. In tal caso, nessun pacchetto AEM dovrebbe dichiarare una dipendenza da esso. Il motivo è perché pacchetti di codice immutabile che solo contengono bundle OSGi, non sono registrati con AEM Gestione pacchetti. Pertanto, qualsiasi pacchetto AEM che dipende da esso ha una dipendenza non soddisfatta e non riesce a installare.

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

Dipendenze dei pacchetti di distribuzione semplici

Il caso semplice imposta il 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 dei pacchetti di distribuzione complesse

Le distribuzioni complesse si espandono in base al caso semplice e impostano le dipendenze tra il contenuto mutabile corrispondente e i pacchetti di codice immutabile. Se necessario, è possibile stabilire le dipendenze 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 e distribuzione locali

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

Frammenti XML POM

Di seguito sono riportati i file 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 un <packageType>.

Tipi di pacchetti codice (immutabili)

I pacchetti di codice devono impostare i relativi packageType a application.

In ui.apps/pom.xml, il <packageType>application</packageType> direttive di configurazione della build di filevault-package-maven-plugin dichiarazione del plug-in che 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.apps</name>
        <packageType>application</packageType>
        <accessControlHandling>merge</accessControlHandling>
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Tipi di pacchetti di contenuti (mutabili)

I pacchetti di contenuti devono impostare le rispettive packageType a content.

In ui.content/pom.xml, il <packageType>content</packageType> direttiva di configurazione della build del filevault-package-maven-plugin dichiarazione del plug-in che 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 la 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. Il contenitore (all) deve essere il singolo pacchetto distribuito tramite Cloud Manager, che a sua volta incorpora tutti i pacchetti richiesti di codice e contenuto.

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

Gli script Repo Init che contengono gli script Repo Init sono definiti in RepositoryInitializer Configurazione di fabbrica OSGi tramite scripts proprietà. Poiché questi script sono definiti nelle configurazioni OSGi, possono essere facilmente delimitati dalla modalità di esecuzione utilizzando ../config.<runmode> semantica delle cartelle.

Poiché gli script sono in genere dichiarazioni su più righe, è più semplice definirli nella .config 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
"]

Il scripts La proprietà OSGi contiene le direttive definite dalla Lingua iniziale dell’archivio 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 creare un pacchetto con la 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 quanto segue <embeddeds> direttive al filevault-package-maven-plugin dichiarazione plugin. Ricorda: non utilizzare il <subPackages> configurazione. Questo perché include 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 filtro del pacchetto contenitore

In all del progetto filter.xml (all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml), include qualsiasi -packages cartelle che contengono pacchetti secondari da distribuire:

<filter root="/apps/my-app-packages"/>

Se più /apps/*-packages sono utilizzati nelle destinazioni incorporate, quindi devono essere elencati tutti qui.

Archivi Maven di terze parti

Nel progetto del reattore pom.xml, aggiungi eventuali direttive dell’archivio Maven pubblico di terze parti necessarie. Il valore completo <repository> deve essere disponibile dal provider dell’archivio di terze parti.

<repositories>
  ...
  <repository>
      <id>3rd-party-repository</id>
      <name>Public Third-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 dei pacchetti tra ui.apps da ui.content Pacchetti

In ui.content/pom.xml, aggiungi quanto segue <dependencies> direttive al filevault-package-maven-plugin dichiarazione 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 maven-clean-plugin plug-in che pulisce la directory di destinazione prima di una 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 tramite Maven
• Plug-in Maven pacchetto contenuti FileVault