L’archétype de projet AEM et le plug-in Maven FileVault Content font partie des thèmes abordés dans cet article. Vous êtes donc invité à vous familiariser avec ces concepts.
Cet article décrit les modifications requises pour que les projets Maven Adobe Experience Manager soient compatibles avec AEM as a Cloud Service, en veillant à ce qu’ils respectent la division entre contenu modifiable et non modifiable, à ce que les dépendances soient établies pour créer des déploiements déterministes non conflictuels et à ce qu’ils soient mis en package dans une structure déployable.
Les déploiements d’applications AEM doivent être constitués d’un seul package AEM. Ce package doit, à son tour, contenir des sous-packages qui comprennent tout ce dont l’application a besoin pour fonctionner, y compris le code, la configuration et tout contenu de base nécessaire.
AEM requiert une séparation du contenu et du code, ce qui signifie qu’un même package de contenu ne peut pas être déployé à la fois dans les zones /apps
et dans les zones accessibles en écriture au moment de l’exécution (/content
, /conf
, /home
ou toute zone autre que /apps
) du référentiel. L’application doit séparer le code et le contenu dans des packages distincts en vue du déploiement dans AEM.
La structure de package décrite dans ce document est compatible avec les déploiements de développement en local et les déploiements d’AEM Cloud Service.
Les configurations décrites dans ce document sont fournies par AEM Project Maven Archetype 24 ou version ultérieure.
/apps
et /libs
sont considérées comme des zones non modifiables d’AEM, car elles ne peuvent faire l’objet d’aucune modification (création, mise à jour ou suppression) après le démarrage d’AEM (c’est-à-dire lors de l’exécution). Toute tentative de modification d’une zone immuable au moment de l'exécution échouera.
Toutes les autres zones du référentiel (/content
, /conf
, /var
, /etc
, /oak:index
, /system
, /tmp
, etc.) peuvent, en revanche, être modifiées au moment de l’exécution.
Comme dans les versions précédentes d’AEM, /libs
ne doit pas être modifié. Seul le code de produit AEM peut être déployé sur /libs
.
Les index Oak (/oak:index
) sont gérés spécifiquement par le processus de déploiement d’AEM as a Cloud Service. En effet, Cloud Manager doit attendre le déploiement d’un nouvel index et la réindexation complète avant de passer à la nouvelle image de code.
Ainsi, bien que les index Oak soient modifiables au moment de l’exécution, ils doivent être déployés sous forme de code pour pouvoir être installés avant les packages modifiables. Les configurations /oak:index
font donc partie du package de code, mais pas du package de contenu, comme décrit ci-dessous.
Pour plus d’informations sur l’indexation dans AEM as a Cloud Service, voir le document Recherche et indexation de contenu.
Ce diagramme présente un aperçu de la structure de projet recommandée et des artefacts de déploiement du package.
La structure de déploiement d’application recommandée est la suivante :
Le fichier Jar du bundle OSGi est généré et directement incorporé dans l’ensemble du projet.
Le package ui.apps
contient tout le code à déployer. Il est déployé uniquement sur /apps
. Voici un aperçu des éléments courants du package ui.apps
:
/apps/my-app/components
/apps/my-app/clientlibs
/libs
/apps/cq
, /apps/dam/
, etc./apps/settings
rep:policy
pour tout chemin d’accès sous /apps
Le même code doit être déployé dans tous les environnements. C’est indispensable pour garantir que la confiance dans l’environnement d’évaluation s’applique également en production. Pour plus d’informations, voir la section Modes d’exécution.
ui.content
contient l’ensemble du contenu et de la configuration. Le package de contenu contient toutes les définitions de nœud qui ne se trouvent pas dans les packages ui.apps
ou ui.config
ou, en d’autres termes, tout ce qui ne se trouve pas dans /apps
ou /oak:index
. Voici un aperçu des éléments courants du package ui.content
:
/conf
/content
, /content/dam
, etc./content/cq:tags
/etc
Le package all
est un package conteneur n’incluant QUE des artefacts déployables, le fichier Jar du bundle OSGI, ui.apps
, ui.config
et des packages ui.content
en tant qu’incorporations. Le package all
ne doit pas comporter de contenu ou de code propre, mais à la place doit déléguer tout le déploiement sur le référentiel à ses sous-packages ou aux fichiers Jar du bundle OSGi.
Les modules sont désormais inclus à l’aide de la configuration intégrée du plug-in FileVault Package Maven au lieu de la configuration <subPackages>
.
Pour les déploiements Experience Manager complexes, il peut être souhaitable de créer plusieurs projets/packages ui.apps
, ui.config
et ui.content
représentant des clients ou des sites spécifiques dans AEM. Dans ce cas, assurez-vous que la division entre contenu modifiable et non modifiable est respectée et que les packages de contenu et les fichiers Jar du bundle OSGi requis sont incorporés sous la forme de sous-packages dans le package du conteneur all
.
Une structure complexe d’un package de contenu de déploiement peut, par exemple, se présenter comme suit :
all
intègre les packages suivants afin de créer un artefact de déploiement unique
common.ui.apps
déploie le code requis par les sites A et Bsite-a.core
requis par le site Asite-a.ui.apps
déploie le code requis par le site Asite-a.ui.config
déploie les configurations OSGi requises par le site Asite-a.ui.content
déploie le contenu et la configuration requis par le site Asite-b.core
requis par le site Bsite-b.ui.apps
déploie le code requis par le site Bsite-b.ui.config
déploie les configurations OSGi requises par le site Bsite-b.ui.content
déploie le contenu et la configuration requis par le site BLe package ui.config
contient toutes les configurations OSGi :
/apps/my-app/osgiconfig
/apps/my-app/osgiconfig/config
/apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
config.<runmode>
approprié, comme indiqué ci-dessus, et être utilisées pour définir :
Si d’autres projets AEM, eux-mêmes composés de leur propre code et de leurs propres packages de contenu, sont utilisés par le déploiement AEM, leurs packages conteneurs doivent être incorporés dans le package all
du projet.
Par exemple, un projet AEM incluant deux applications AEM de fournisseurs peut se présenter comme suit :
all
intègre les packages suivants afin de créer un artefact de déploiement unique
core
requis par l’application AEMui.apps
déploie le code requis par l’application AEMui.config
déploie les configurations OSGi requises par l’application AEMui.content
déploie le contenu et la configuration requis par l’application AEMvendor-x.all
déploie tous les éléments (code et contenu) requis par l’application du fournisseur Xvendor-y.all
déploie tout les éléments (code et contenu) requis par l’application du fournisseur YLes packages doivent être marqués avec le type déclaré. Les types de packages permettent de clarifier l’objectif et le déploiement d’un package.
packageType
sur container
. Les packages de conteneurs ne doivent pas contenir de nœuds standard. Seuls les lots OSGi, les configurations et les sous-packages sont autorisés. Les conteneurs dans AEM as a Cloud Service ne sont pas autorisés à utiliser les hooks d’installation.packageType
sur application
.packageType
sur content
.Pour plus d’informations, consultez la documentation d’Apache Jackrabbit FileVault - Plug-in Maven pour les packages, les Types de packages Apache Jackrabbit et le Fragment de code de configuration FileVault Maven ci-dessous.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
Par défaut, Adobe Cloud Manager collecte tous les packages générés par la version Maven. Cependant, étant donné que le package de conteneur (all
) est l’artefact de déploiement unique qui comprend tous les packages de code et de contenu, nous devons nous assurer que seul le package de conteneur (all
) est déployé. Pour ce faire, les autres modules générés par la version Maven doivent être marqués avec la configuration suivante du plug-in Maven FileVault Content Package : <properties><cloudManagerTarget>none</cloudManageTarget></properties>
.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
Repo Init fournit des instructions, ou scripts, qui définissent les structures JCR, allant des structures de nœud courantes comme les arborescences de dossiers, aux utilisateurs, aux utilisateurs de service, aux groupes et à la définition d’ACL.
Les principaux avantages de Repo Init sont que ce dernier comporte des autorisations implicites pour exécuter toutes les actions définies par ses scripts et qu’il est appelé au début du cycle de vie du déploiement pour s’assurer que toutes les structures JCR requises existent au moment de l’exécution du code temporel.
Bien que les scripts Repo Init résident eux-mêmes dans le projet ui.config
en tant que scripts, ils peuvent et doivent être utilisés pour définir les structures mutables suivantes :
Les scripts Repo Init sont stockés en tant qu’entrées scripts
des configurations d’usine OSGi RepositoryInitializer
. Ils peuvent donc être implicitement ciblés par le mode d’exécution, ce qui permet d’établir des différences entre les scripts Repo Init des services d’auteur et de publication AEM, voire entre les environnements (développement, évaluation et production).
Les configurations OSGi Repo Init sont mieux écrites dans le .config
format de configuration OSGi, car elles prennent en charge plusieurs lignes, ce qui est une exception aux bonnes pratiques d’utilisation de .cfg.json
pour définir des configurations OSGi.
Notez que lors de la définition d’utilisateurs et de groupes, seuls les groupes considérés comme faisant partie de l’application, et essentiels à son fonctionnement, doivent être définis ici. Dans les organisations, les utilisateurs et les groupes doivent toujours être définis au moment de l’exécution dans AEM ; par exemple, si un workflow personnalisé affecte du travail à un groupe nommé, ce groupe doit être défini via Repo Init dans l’application AEM. Toutefois, si le regroupement est simplement organisationnel, comme « Équipe de Jean » et « Équipe de Valérie », le groupe sera défini et géré plus efficacement lors de l’exécution dans AEM.
Les scripts Repo Init doivent être définis dans le champ scripts
intégré et la configuration references
ne fonctionnera pas.
Le vocabulaire complet des scripts Repo Init est disponible dans la documentation d’Apache Sling Repo Init.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code Repo Init ci-dessous.
Les packages de code exigent que la configuration du plug-in Maven FileVault fasse référence à un <repositoryStructurePackage>
qui s’assure que les dépendances structurelles sont correctes (pour s’assurer qu’un package de code ne s’installe pas sur un autre). Vous pouvez créer votre propre package de structure de référentiel pour votre projet.
Cette exigence porte uniquement sur les packages de code, c’est-à-dire tout package marqué avec <packageType>application</packageType>
.
Pour savoir comment créer un package de structure de référentiel pour votre application, voir Développement d’un package de structure de référentiel.
Notez que les packages de contenu (<packageType>content</packageType>
) n’ont pas besoin de ce package de structure de référentiel.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
Les packages de contenu ou de code sont placés dans un dossier « sidecar » spécial et peuvent être ciblés en vue d’une installation sur AEM Author, AEM Publish, ou les deux, à l’aide de la configuration <embeddeds>
du plug-in Maven FileVault. Notez que la configuration <subPackages>
ne doit pas être utilisée.
Scénarios d’utilisation courants :
Pour cibler AEM Author, AEM Publish ou les deux, le package est incorporé dans le package conteneur all
dans un emplacement de dossier spécial, au format suivant :
/apps/<app-name>-packages/(content|application|container)/install(.author|.publish)?
Analyse de cette structure de dossiers :
Le dossier de premier niveau doit être /apps
.
Le dossier de deuxième niveau représente l’application, avec le -packages
ajouté après le nom du dossier. Bien souvent, tous les sous-packages sont incorporés dans un seul dossier de deuxième niveau ; toutefois, il est possible de créer un nombre illimité de dossiers de deuxième niveau pour représenter au mieux la structure logique de l’application :
/apps/my-app-packages
/apps/my-other-app-packages
/apps/vendor-packages
Par convention, le suffixe -packages
est ajouté au nom des dossiers dans lesquels sont incorporés des sous-packages. Cela permet de s’assurer que les packages de contenu et de code du déploiement ne sont pas déployés dans le(s) dossier(s) cible(s) d’un sous-package /apps/<app-name>/...
, ce qui provoque un comportement d’installation cyclique destructeur.
Le dossier de troisième niveau doit être
application
, content
ou container
application
contient des packages de code.content
contient des packages de contenu.container
contient les packages d’applications supplémentaires pouvant être inclus par l’application AEM.Le dossier de quatrième niveau contient les sous-packages. Il doit s’agir de l’un des dossiers suivants :
install
pour effectuer une installation sur AEM Author et AEM Publishinstall.author
pour effectuer une installation uniquement sur AEM Authorinstall.publish
pour effectuer une installation uniquement sur AEM Publishinstall.author
et install.publish
sont des cibles prises en charge. Les autres modes d’exécution ne sont pas pris en charge.Par exemple, un déploiement qui contient des packages spécifiques à AEM Author et AEM Publish peut se présenter comme suit :
all
intègre les packages suivants afin de créer un artefact de déploiement unique
ui.apps
incorporé dans /apps/my-app-packages/application/install
déploie le code sur AEM Author et AEM Publishui.apps.author
incorporé dans /apps/my-app-packages/application/install.author
déploie le code uniquement sur AEM Authorui.content
incorporé dans /apps/my-app-packages/content/install
déploie le contenu et la configuration sur AEM Author et AEM Publishui.content.publish
incorporé dans /apps/my-app-packages/content/install.publish
déploie le contenu et la configuration uniquement sur AEM PublishPour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
En raison de l’incorporation des sous-packages de code et de contenu dans le package conteneur, les chemins d’accès cibles incorporés doivent être ajoutés au fichier filter.xml
du projet de conteneur pour s’assurer que les packages incorporés sont inclus dans le package conteneur lors de sa création.
Il vous suffit d’ajouter les entrées <filter root="/apps/<my-app>-packages"/>
pour les dossiers de deuxième niveau contenant des sous-packages à déployer.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
Tous les packages doivent être disponibles via le référentiel d’artefacts Maven public d’Adobe ou un référentiel d’artefacts Maven tiers accessible au public pouvant être référencé.
Si les packages tiers se trouvent dans le référentiel d’artefacts Maven public d’Adobe, aucune configuration supplémentaire n’est nécessaire pour qu’Adobe Cloud Manager puisse résoudre les artefacts.
Si les packages tiers se trouvent dans le référentiel d’artefacts Maven tiers public, ce dernier doit être enregistré dans le fichier pom.xml
du projet et incorporé suivant la méthode décrite ci-dessus.
Les applications/connecteurs tiers doivent être incorporés à l’aide de son package all
en tant que conteneur dans le package (all
) du conteneur de votre projet.
L’ajout de dépendances Maven suivant les pratiques Maven standard et l’incorporation d’artefacts tiers (packages de code et contenu) sont décrits ci-dessus.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
ui.apps
et ui.content
Pour assurer l’installation correcte des packages, il est recommandé d’établir des dépendances entre les packages.
La règle est que les packages contenant du contenu modifiable (ui.content
) doivent dépendre du code non modifiable (ui.apps
) qui prend en charge le rendu et l’utilisation du contenu modifiable.
Une exception notable à cette règle générale est que le package de code non modifiable (ui.apps
ou autre) contient uniquement des bundles OSGi. Si tel est le cas, aucun package AEM ne doit déclarer une dépendance à son égard. En effet, les packages de code non modifiables contenant uniquement des lots OSGi ne sont pas enregistrés auprès du Gestionnaire de packages d’AEM. Dans ce cas, un package AEM dépendant de celui-ci aura une dépendance insatisfaite et ne pourra pas être installé.
Pour obtenir un fragment de code complet, reportez-vous à la section Fragments de code XML POM ci-dessous.
Les schémas courants applicables aux dépendances des packages de contenu sont les suivants :
Dans ce scénario, le package de contenu modifiable ui.content
est défini de telle sorte qu’il dépende du package de code non modifiable ui.apps
.
all
ne comporte aucune dépendance
ui.apps
ne comporte aucune dépendanceui.content
dépend de ui.apps
Les déploiements complexes étendent le scénario de déploiement simple et définissent les dépendances entre les packages de contenu modifiable et non modifiable correspondants. Suivant les besoins, des dépendances peuvent également être établies entre des packages de code non modifiable.
all
ne comporte aucune dépendance
common.ui.apps.common
ne comporte aucune dépendancesite-a.ui.apps
dépend de common.ui.apps
site-a.ui.content
dépend de site-a.ui.apps
site-b.ui.apps
dépend de common.ui.apps
site-b.ui.content
dépend de site-b.ui.apps
L’organisation et les structures de projet décrites dans cet article sont entièrement compatibles avec les instances AEM de développement en local.
Vous trouverez, ci-après, des fragments de code de configuration pom.xml
Maven pouvant être ajoutés aux projets Maven pour respecter les recommandations ci-dessus.
Les packages de code et de contenu qui sont déployés sous la forme de sous-packages doivent déclarer un type application ou contenu, en fonction de leur contenu.
Le projet all/pom.xml
du conteneur ne déclare pas de <packageType>
.
Les packages de code doivent définir leur packageType
sur application
.
Dans le fichier ui.apps/pom.xml
, la directive de configuration de version <packageType>application</packageType>
de la déclaration du plug-in filevault-package-maven-plugin
déclare son type de package.
...
<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>
...
Les packages de contenu doivent définir leur packageType
sur content
.
Dans le fichier ui.content/pom.xml
, la directive de configuration de version <packageType>content</packageType>
de la déclaration du plug-in filevault-package-maven-plugin
déclare son type de package.
...
<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>
...
Dans chaque projet générant un package, à l’exception du projet conteneur (all
), ajoutez <cloudManagerTarget>none</cloudManagerTarget>
à la configuration <properties>
de la déclaration du plug-in filevault-package-maven-plugin
pour vous assurer que le déploiement n’est pas effectué par Adobe Cloud Manager. Le package conteneur (all
) doit être le package unique déployé via Cloud Manager qui, à son tour, incorpore tous les packages de code et de contenu requis.
...
<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>
...
Les scripts Repo Init sont définis dans la configuration d’usine OSGi RepositoryInitializer
via la propriété scripts
. Puisque ces scripts sont définis dans les configurations OSGi, ils peuvent être facilement définis par le mode d’exécution à l’aide de la sémantique de dossier ../config.<runmode>
habituelle.
Parce que les scripts sont généralement des déclarations multilignes, il est plus facile de les définir dans le fichier .config
que dans le format .cfg.json
basé sur 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 propriété OSGi scripts
contient des directives définies par le langage Repo Init d’Apache Sling.
Dans le fichier ui.apps/pom.xml
, ainsi que dans tout autre fichier pom.xml
qui déclare un package de code (<packageType>application</packageType>
), ajoutez la configuration de package de structure de référentiel suivante au plug-in Maven FileVault. Vous pouvez créer votre propre package de structure de référentiel pour votre projet.
...
<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>
...
Dans le fichier all/pom.xml
, ajoutez les directives <embeddeds>
suivantes à la déclaration du plug-in filevault-package-maven-plugin
. Pour rappel, n’utilisez pas la configuration <subPackages>
, car elle inclut les sous-packages dans /etc/packages
plutôt que dans /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>
...
Dans le fichier filter.xml
du projet all
(all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml
), incluez tout dossier -packages
contenant des sous-packages à déployer :
<filter root="/apps/my-app-packages"/>
Si plusieurs /apps/*-packages
sont utilisés dans les cibles incorporées, ils doivent tous être énumérés ici.
L’ajout d’autres référentiels Maven peut rallonger les délais de création, car d’autres référentiels Maven seront vérifiés pour en déterminer les dépendances.
Dans le fichier pom.xml
du projet Reactor, ajoutez toute directive de référentiel Maven public tierce qui s’avère nécessaire. La configuration <repository>
complète doit être disponible auprès du fournisseur de référentiels tiers.
<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
et ui.content
Dans le fichier ui.content/pom.xml
, ajoutez les directives <dependencies>
suivantes à la déclaration du plug-in filevault-package-maven-plugin
.
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<dependencies>
<!-- Declare the content package dependency in the ui.content/pom.xml on the ui.apps project -->
<dependency>
<groupId${project.groupId}</groupId>
<artifactId>my-app.ui.apps</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
...
</configuration>
</plugin>
...
Dans le fichier all/pom.xml
, ajoutez le plug-in maven-clean-plugin
qui nettoie le répertoire cible avant la génération d’une 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>