Acquisisci familiarità con le Utilizzo di Archetipo progetto AEMe Plug-in FileVault Content Maven poiché questo articolo si basa su questi insegnamenti e concetti.
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 di contenuti mutabili e immutabili, che le dipendenze siano stabilite per creare distribuzioni deterministiche non in conflitto e che siano 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 della linea 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.
Le configurazioni descritte in questo documento sono fornite da Progetto AEM Maven Archetipo 24 o successivo.
/apps
e /libs
sono considerate aree immutabili di AEM poiché non possono essere modificate (create, aggiornate, eliminate) dopo l’avvio di AEM (ad es. in fase di runtime). Eventuali tentativi di modifica di un’area immutabile in fase di runtime avranno esito negativo.
Tutto il resto nell’archivio, /content
, /conf
, /var
, /etc
, /oak:index
, /system
, /tmp
, ecc. sono tutti mutabile , ovvero possono essere modificate in fase di runtime.
Come nelle versioni precedenti dell’AEM, /libs
non devono essere modificati. Solo il codice prodotto AEM può distribuire a /libs
.
Indici Oak (/oak:index
) sono gestite in modo specifico dal processo di implementazione as a Cloud Service dell'AEM. Questo perché 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.
Per ulteriori dettagli sull’indicizzazione in AEM as a Cloud Service, consulta il documento Ricerca e indicizzazione dei contenuti.
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:
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:
/apps/my-app/components
/apps/my-app/clientlibs
/libs
/apps/cq
, /apps/dam/
, ecc./apps/settings
rep:policy
per qualsiasi percorso in /apps
Lo stesso codice deve essere distribuito in tutti gli ambienti. Ciò è necessario per garantire un livello di affidabilità delle convalide anche nell’ambiente stage in produzione. Per ulteriori informazioni, consulta la sezione su Modalità di esecuzione.
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:
/conf
/content
, /content/dam
, ecc./content/cq:tags
/etc
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 propria iniziativa, ma delega l’intera distribuzione all’archivio ai relativi pacchetti secondari 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. In tal caso, 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 siano 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 Bsite-a.core
JAR del bundle OSGi richiesto dal sito Asite-a.ui.apps
distribuisce il codice richiesto dal sito Asite-a.ui.config
distribuisce le configurazioni OSGi richieste dal sito Asite-a.ui.content
distribuisce il contenuto e la configurazione richiesti dal sito Asite-b.core
JAR bundle OSGi richiesto dal sito Bsite-b.ui.apps
distribuisce il codice richiesto dal sito Bsite-b.ui.config
distribuisce le configurazioni OSGi richieste dal sito Bsite-b.ui.content
distribuisce il contenuto e la configurazione richiesti dal sito BIl ui.config
il pacchetto contiene tutti Configurazioni OSGi:
/apps/my-app/osgiconfig
/apps/my-app/osgiconfig/config
/apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
config.<runmode>
come descritto in precedenza e può essere utilizzato per definire:
Se altri progetti AEM, a loro volta costituiti da pacchetti di codice e 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 AEMui.apps
distribuisce il codice richiesto dall’applicazione AEMui.config
implementa le configurazioni OSGi richieste dall’applicazione AEMui.content
implementa il contenuto e la configurazione richiesti dall’applicazione AEMvendor-x.all
distribuisce tutto il necessario (codice e contenuto) per l’applicazione X del fornitorevendor-y.all
distribuisce tutto il necessario (codice e contenuto) per l’applicazione Y del fornitoreI 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.
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.packageType
a application
.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.
Consulta la Frammenti XML POM per uno snippet completo.
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>
.
Consulta la Frammenti XML POM per uno snippet completo.
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 la presenza di autorizzazioni implicite per eseguire tutte le azioni definite dagli script e il richiamo all’inizio del ciclo di vita della distribuzione, che garantisce l’esistenza di tutte le strutture JCR richieste 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:
Gli script di inizializzazione dell’archivio sono memorizzati come scripts
voci di RepositoryInitializer
Le configurazioni di fabbrica OSGi, e quindi, possono essere impostate come destinazione implicita dalla modalità di esecuzione, consentendo differenze tra gli script Repo Init 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.
Tieni presente che, quando definisci Utenti e Gruppi, solo i gruppi sono considerati parte dell’applicazione e devono essere qui definiti come parte integrante della sua funzione. Utenti e gruppi dell’organizzazione devono essere ancora 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 tramite Repo Init nell’applicazione AEM, tuttavia se il raggruppamento è puramente organizzativo, come "Team di Wendy" e "Team di Sean", è meglio definirli e gestirli in fase di runtime in AEM.
Script di inizializzazione archivio deve essere definito in linea scripts
e references
la configurazione non funzionerà.
Il vocabolario completo per gli script Repo Init è disponibile sul sito Documentazione di avvio dell’archivio Sling Apache.
Consulta la Snippet di inizializzazione archivio per uno snippet completo.
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 venga installato su un altro). È possibile creare un pacchetto con la 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 di struttura dell’archivio per l’applicazione, consulta Sviluppare un pacchetto con la struttura dell’archivio.
Tieni presente che i pacchetti di contenuti (<packageType>content</packageType>
) non richiede questo pacchetto con struttura dell’archivio.
Consulta la Frammenti XML POM per uno snippet completo.
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. Tieni presente che <subPackages>
non deve essere utilizzata.
I casi d’uso comuni includono:
Per eseguire il targeting dell’autore dell’AEM, della pubblicazione dell’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
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
application
la cartella contiene pacchetti di codicecontent
la cartella contiene i pacchetti di contenuticontainer
cartella contiene qualsiasi pacchetti applicativi aggiuntivi che potrebbero essere incluse nella domanda AEM.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 Publishinstall.author
per eseguire l’installazione solo su AEM Authorinstall.publish
a solo installare su pubblicazione AEM Nota che solo 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 AEMui.apps.author
incorporato in /apps/my-app-packages/application/install.author
distribuisce il codice solo all’autore AEMui.content
incorporato in /apps/my-app-packages/content/install
distribuisce contenuti e configurazione sia all’autore AEM che alla pubblicazione AEMui.content.publish
incorporato in /apps/my-app-packages/content/install.publish
distribuisce contenuti e configurazione solo per la pubblicazione AEMConsulta la Frammenti XML POM per uno snippet completo.
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
per garantire che i pacchetti incorporati siano 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.
Consulta la Frammenti XML POM per uno snippet completo.
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 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 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.
Consulta la Frammenti XML POM per uno snippet completo.
ui.apps
da ui.content
PacchettiPer 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. Questo perché i pacchetti di codice non modificabili solo I bundle OSGi che li contengono non sono registrati con AEM Gestione pacchetti, di conseguenza, qualsiasi pacchetto AEM che dipenda da esso avrà una dipendenza insoddisfatta e non potrà essere installato.
Consulta la Frammenti XML POM per uno snippet completo.
I pattern comuni per le dipendenze dei pacchetti di contenuti sono:
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 dipendenzeui.content
dipende da ui.apps
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 dipendenzesite-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
Le strutture e l'organizzazione del progetto descritte in questo articolo sono completamente compatibile sviluppo locale istanze AEM.
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.
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.
Il contenitore all/pom.xml
progetto non dichiarare un <packageType>
.
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>
...
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>
...
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>
...
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 la ../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.
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>
...
In all/pom.xml
, aggiungi quanto segue <embeddeds>
direttive al filevault-package-maven-plugin
dichiarazione plugin. Ricorda: non utilizzare il <subPackages>
, in quanto 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>
...
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 più /apps/*-packages
sono utilizzati nelle destinazioni incorporate, quindi devono essere elencati tutti qui.
L’aggiunta di più archivi Maven può estendere i tempi di generazione Maven, in quanto verranno verificati eventuali dipendenze da altri archivi Maven.
Nel progetto del reattore pom.xml
, aggiungi eventuali direttive dell’archivio Maven pubblico di terze parti necessarie. Il valore completo <repository>
La configurazione di 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>
ui.apps
da ui.content
PacchettiIn 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>
...
In all/pom.xml
aggiungi maven-clean-plugin
plug-in per la pulizia della directory di destinazione prima della generazione 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>