Struttura dei progetti AEM

SUGGERIMENTO

Acquisisci familiarità con l'utilizzo di baseAEM Project Archetype e con il plug-in FileVault Content Maven, man mano che questo articolo si basa su tali conoscenze e concetti.

Questo articolo illustra le modifiche necessarie per i progetti Adobe Experience Manager Maven AEM come Cloud Service compatibile, garantendo che rispettino la divisione 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 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.

SUGGERIMENTO

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

Aree variabile e immutabili del repository

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

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.

AVVERTENZA

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

Indici Oak

Gli indici di quercia (/oak:index) sono gestiti specificamente dal AEM come processo di distribuzione del Cloud Service. Questo perché Cloud Manager deve aspettare che un nuovo indice venga distribuito e riclassificato 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.

SUGGERIMENTO

Per ulteriori dettagli sull'indicizzazione in AEM come Cloud Service, consultare il documento Content Search and Indexing(Ricerca e indicizzazione dei contenuti).

struttura pacchetto progetto Experience Manager

Questo diagramma fornisce una panoramica della struttura di progetto consigliata e degli artifact di distribuzione del pacchetto.

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 ui.apps pacchetto contiene tutto il codice da distribuire e solo da distribuire a /apps. Gli elementi comuni del ui.apps pacchetto includono, tra l'altro:

    • Definizioni dei componenti e script HTL
      • /apps/my-app/components
    • JavaScript e CSS (tramite librerie client)
      • /apps/my-app/clientlibs
    • Sovrapposizioni di /libs
      • /apps/cq, /apps/dam/, etc.
    • Configurazioni basate sul contesto di fallback
      • /apps/settings
    • ACL (autorizzazioni)
      • Qualsiasi rep:policy percorso in /apps
  • Il ui.config pacchetto 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 AEM di destinazione come destinazioni di distribuzione Cloud Service
      • /apps/my-app/osgiconfig/config
    • Esegui cartelle di configurazione OSGi specifiche della modalità che contengono configurazioni OSGi predefinite applicabili a tutti i AEM di destinazione come destinazioni di distribuzione Cloud Service
      • /apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
    • Script di configurazione Repo Init OSGi
      • Repo Init è il metodo consigliato per distribuire (modificabile) contenuto che fa parte logicamente dell'applicazione AEM. Le configurazioni di Repo Init OSGi devono trovarsi nella config.<runmode> cartella appropriata come indicato sopra e devono essere utilizzate per definire:
        • Strutture contenuto di base
        • Utenti
        • Utenti del servizio
        • Gruppi
        • ACL (autorizzazioni)

Pacchetti di contenuti

  • Il ui.content pacchetto contiene tutto il contenuto e la configurazione. Il pacchetto di contenuto contiene tutte le definizioni dei nodi non presenti nei ui.apps pacchetti o ui.config nei pacchetti, o in altre parole, in elementi non presenti /apps o /oak:index. Gli elementi comuni del ui.content pacchetto includono, tra l'altro:
    • Configurazioni basate sul 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, etc.
    • Tassonomie di tag gestite
      • /content/cq:tags
    • Nodi legacy ecc. (Idealmente, migrare questi a posizioni diverse/ecc.)
      • /etc

Pacchetti contenitore

  • Il all pacchetto è un contenitore che include SOLO artefatti distribuibili, il file Jar del pacchetto OSGI ui.apps, ui.config e ui.content i pacchetti come embeds. The all package must not have any content or code of its own, but rather delegate all deployment to the repository to its sub-packages or OSGi bundle Jar files.

    I pacchetti ora sono inclusi utilizzando la configurazione incorporata del plug-in MavenFileVault, anziché la <subPackages> configurazione.

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

    Ad esempio, una struttura complessa di pacchetti di contenuto di distribuzione potrebbe avere l'aspetto seguente:

    • all il pacchetto di contenuti incorpora i pacchetti seguenti, per creare un artefatto di distribuzione unico
      • common.ui.apps distribuisce il codice richiesto sia dal sito A che dal sito B
      • site-a.core Bacheca OSGi necessaria per il 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 Bacheca OSGi necessaria per il 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 altri progetti AEM, anch'essi costituiti da pacchetti di codice e contenuto propri, vengono utilizzati dalla distribuzione AEM, i loro pacchetti contenitore dovrebbero essere incorporati nel all pacchetto del progetto.

Ad esempio, un progetto AEM che include 2 applicazioni AEM fornitore potrebbe avere l'aspetto seguente:

  • all il pacchetto di contenuti incorpora i pacchetti seguenti, per creare un artefatto di distribuzione unico
    • core Bacheca OSGi necessaria per l'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 tutto (codice e contenuto) richiesto dall'applicazione Y del fornitore

Tipi di pacchetti

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

  • I pacchetti contenitore devono impostare packageType su container.
  • 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.

SUGGERIMENTO

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

SUGGERIMENTO

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

  • Strutture contenuto di base
  • 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 Repo Init di AEM Author e AEM Publish Services o anche tra ambienti (Dev, Stage e Prod).

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

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.

SUGGERIMENTO

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 diApache Sling Repo Init.

SUGGERIMENTO

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 pacchettodi struttura del repository.

I pacchetti di contenuto (<packageType>content</packageType>) non richiedono questo pacchetto struttura archivio.

SUGGERIMENTO

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

Incorporazione di pacchetti

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|container)/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
    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 or container

    • La application cartella contiene pacchetti di codice
    • La content cartella contiene pacchetti di contenuto
    • La container cartella contiene tutti i pacchetti di applicazione aggiuntivi che possono essere inclusi dall'applicazione AEM.
      Il 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 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
SUGGERIMENTO

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.

SUGGERIMENTO

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.

I connettori/applicazioni di terze parti devono essere incorporati utilizzando il all pacchetto come contenitore nel pacchetto contenitore del progetto (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.

SUGGERIMENTO

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.

SUGGERIMENTO

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
    • 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 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 modificati in base alla modalità di esecuzione utilizzando la semantica ../config.<runmode> delle cartelle tipica.

Poiché gli script sono in genere una dichiarazione su più righe, è più facile definirli nel .config file rispetto al formato basato su JSON .cfg.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 le direttive definite dalla lingua Repo Init diApache 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|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 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

AVVERTENZA

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>

Risorse aggiuntive

In questa pagina