AEM Project-struktur
I den här artikeln beskrivs de ändringar som krävs för Adobe Experience Manager Maven-projekt som är AEM as a Cloud Service-kompatibla genom att säkerställa att de respekterar delningen av ändringsbart och oföränderligt innehåll. Beroenden skapas också för att skapa icke-konfliktskapande, deterministiska distributioner, och de paketeras i en distributionsbar struktur.
AEM programdistributioner måste bestå av ett enda AEM-paket. Paketet ska i sin tur innehålla delpaket som innehåller allt som krävs för att programmet ska fungera, inklusive kod, konfiguration och allt baslinjeinnehåll som stöds.
AEM kräver en separation av content och code, vilket innebär att ett enstaka innehållspaket inte kan distribueras till både /apps och körningsskrivbara områden (till exempel /content, /conf, /home eller något annat som inte är /apps) i databasen. Programmet måste i stället separera kod och innehåll i separata paket för distribution till AEM.
Den paketstruktur som beskrivs i det här dokumentet är kompatibel med både lokala utvecklingsdistributioner och AEM Cloud Service-distributioner.
Variabla kontra oföränderliga områden i databasen mutable-vs-immutable
Områdena /apps och /libs i AEM är oföränderliga. När AEM har startats kan du inte skapa, uppdatera eller ta bort innehåll i dessa områden under körning. Alla försök att ändra ett oföränderligt område vid körning misslyckas.
Allt annat i databasen, /content, /conf, /var, /etc, /oak:index, /system, /tmp och så vidare, är alla muterbara områden, vilket innebär att de kan ändras under körning.
/libs inte ändras. Endast AEM produktkod kan distribueras till /libs.Oak index oak-indexes
AEM as a Cloud Service distributionsprocess hanterar Oak-index (/oak:index). Orsaken är att Cloud Manager måste vänta tills ett nytt index har distribuerats och indexerats om fullständigt innan det går över till den nya kodbilden.
Även om Oak-index kan ändras vid körning måste de därför distribueras som kod så att de kan installeras innan några ändringsbara paket installeras. Därför är /oak:index-konfigurationer en del av kodpaketet och inte en del av innehållspaketet enligt beskrivningen nedan.
Rekommenderad paketstruktur recommended-package-structure
I det här diagrammet visas en översikt över den rekommenderade projektstrukturen och artefakter för paketdistribution.
Den rekommenderade programdistributionsstrukturen är följande:
Kodpaket/OSGi-paket
-
OSGi-paketfilen genereras och bäddas in direkt i hela projektet.
-
Paketet
ui.appsinnehåller all kod som ska distribueras och endast distribueras till/apps. Vanliga element i paketetui.appsinnehåller, men är inte begränsade till:- Komponentdefinitioner och HTML-skript
/apps/my-app/components
- JavaScript och CSS (via klientbibliotek)
/apps/my-app/clientlibs
- Övertäckningar av
/libs/apps/cq,/apps/dam/och så vidare.
- Kontextmedvetna reservkonfigurationer
/apps/settings
- ACL-listor (behörigheter)
- Alla
rep:policyför alla sökvägar under/apps
- Alla
- Förkompilerade paketerade skript
- Komponentdefinitioner och HTML-skript
Innehållspaket
-
Paketet
ui.contentinnehåller allt innehåll och all konfiguration. Innehållspaketet innehåller alla noddefinitioner som inte finns iui.apps- ellerui.config-paketen, eller med andra ord något som inte finns i/appseller/oak:index. Vanliga element i paketetui.contentinnehåller, men är inte begränsade till:- Kontextmedvetna konfigurationer
/conf
- Nödvändiga, komplexa innehållsstrukturer (d.v.s. innehållsbygge som bygger på och sträcker sig utanför de ursprungliga innehållsstrukturer som definierats i Repo Init).
/content,/content/damoch så vidare.
- Styrda taggar för taxonomier
/content/cq:tags
- Äldre
etc-noder (helst migrera dessa noder till platser som inte är/osv)/etc
- Kontextmedvetna konfigurationer
Behållarpaket
-
Paketet
allär ett behållarpaket. Det innehåller endast distributionsbara artefakter som bäddas in: OSGi-paketets JAR-fil ochui.apps-,ui.config- ochui.content-paketen. Paketetallfår inte ha något eget innehåll eller någon egen kod, utan i stället delegera all distribution till databasen till dess underpaket eller OSGi-paketera JAR-filer.Paket inkluderas nu med Maven FileVault-pluginens inbäddade konfiguration i stället för
<subPackages>-konfigurationen.För komplexa Experience Manager-distributioner kan det vara önskvärt att skapa flera projekt/paket för
ui.apps,ui.configochui.contentsom representerar specifika webbplatser eller klientorganisationer i AEM. Om du använder den här metoden bör du respektera uppdelningen mellan muterbart och oföränderligt innehåll. Bädda också in de nödvändiga innehållspaketen och OSGi-paketerade JAR-filer som delpaket iall-behållarinnehållspaketet.En innehållsstruktur för en komplex distribution kan till exempel se ut så här:
-
Innehållspaketet
allbäddar in följande paket för att skapa en enda distributionsartefaktcommon.ui.appsdistribuerar kod som krävs av både plats A och plats Bsite-a.coreOSGi-paket Jar krävs av webbplats Asite-a.ui.appsdistribuerar kod som krävs av plats Asite-a.ui.configdistribuerar OSGi-konfigurationer som krävs för plats Asite-a.ui.contentdistribuerar innehåll och konfiguration som krävs av plats Asite-b.coreOSGi-paket Jar krävs av webbplats Bsite-b.ui.appsdistribuerar kod som krävs av plats Bsite-b.ui.configdistribuerar OSGi-konfigurationer som krävs av plats Bsite-b.ui.contentdistribuerar innehåll och konfiguration som krävs av plats B
-
-
Paketet
ui.configinnehåller alla OSGi-konfigurationer:-
Betraktad kod som tillhör OSGi-paket men inte innehåller vanliga innehållsnoder. Därför markeras den som ett behållarpaket
-
Organisationsmapp som innehåller körlägesspecifika OSGi-konfigurationsdefinitioner
/apps/my-app/osgiconfig
-
En gemensam OSGi-konfigurationsmapp som innehåller standardkonfigurationer för OSGi som gäller för alla AEM as a Cloud Service-måldistributionsmål
/apps/my-app/osgiconfig/config
-
Kör lägesspecifika OSGi-konfigurationsmappar som innehåller standardkonfigurationer för OSGi som gäller för alla AEM as a Cloud Service-måldistributionsmål
/apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
-
Repo Init OSGi-konfigurationsskript
-
Repo Init rekommenderas för att distribuera (muterbart) innehåll som logiskt är en del av AEM-programmet. Repo Init OSGi-konfigurationerna ska placeras i lämplig
config.<runmode>-mapp enligt ovan och användas för att definiera:- Baslinjeinnehållsstrukturer
- Användare
- Tjänstanvändare
- Grupper
- ACL-listor (behörigheter)
-
-
Extra programpaket extra-application-packages
Om andra AEM-projekt, som i sig själva består av sina egna kod- och innehållspaket, används av AEM-distributionen, bör deras behållarpaket bäddas in i projektets all-paket.
Ett AEM-projekt som innehåller två AEM-program från en leverantör kan se ut så här:
-
Innehållspaketet
allbäddar in följande paket för att skapa en enda distributionsartefaktcoreOSGi bundles Jar krävs för AEM-programmetui.appsdistribuerar kod som krävs för AEM-programmetui.configdistribuerar OSGi-konfigurationer som krävs av AEM-programmetui.contentdistribuerar innehåll och konfiguration som krävs för AEM-programmetvendor-x.alldistribuerar allt (kod och innehåll) som krävs av leverantör X-programmetvendor-y.alldistribuerar allt (kod och innehåll) som krävs av leverantörens Y-program
Pakettyper package-types
Paket ska märkas med sin deklarerade pakettyp. Pakettyper gör det lättare att klargöra syftet med och distributionen av ett paket.
- Behållarpaket måste ange
packageTypetillcontainer. Behållarpaket får inte innehålla vanliga noder. Endast OSGi-paket, konfigurationer och underpaket tillåts. Behållare i AEM as a Cloud Service får inte använda installera kopplingar. - Kodpaket (ej ändringsbara) måste ange
packageTypetillapplication. - Innehållspaket (mutable) måste ange
packageTypetillcontent.
Mer information finns i dokumentationen för Apache Jackrabbit FileVault - Package Maven Plugin , Pakettyper för Apache Jackrabbit och konfigurationsfragmentet för FileVault Maven nedan.
Markera paket för distribution med Adobe Cloud Manager marking-packages-for-deployment-by-adoube-cloud-manager
Som standard skördar Adobe Cloud Manager alla paket som produceras av Maven-bygget. Eftersom behållarpaketet (all) är en enda distributionsartefakt som innehåller alla kod och innehållspaket, måste du se till att endast behållarpaketet (all) distribueras. För att säkerställa detta måste andra paket som genereras av Maven-bygget markeras med FileVaults Maven-pluginkonfiguration <properties><cloudManagerTarget>none</cloudManageTarget></properties> för innehållspaket.
Repo Init repo-init
Repo Init innehåller instruktioner, eller skript, som definierar JCR-strukturer, från vanliga nodstrukturer som mappträd till användare, tjänstanvändare, grupper och ACL-definition.
De största fördelarna med Repo Init är att de har implicita behörigheter att utföra alla åtgärder som definieras av deras skript. Sådana skript anropas tidigt under driftsättningens livscykel och säkerställer att alla nödvändiga JCR-strukturer finns när koden körs.
Repo Init-skript som finns i ui.config-projektet som skript kan och bör användas för att definiera följande muterbara strukturer:
- Baslinjeinnehållsstrukturer
- Tjänstanvändare
- Användare
- Grupper
- ACL:er
Repo Init-skript lagras som scripts poster i RepositoryInitializer OSGi-fabrikskonfigurationer. Körningsläget kan implicit rikta in sig på dem. Med den här målgruppsanpassningen kan du skilja på Repo Init-skript mellan AEM Author och AEM Publish Services, eller till och med mellan Dev-, Stage- och Prod-miljöer.
Repo Init OSGi-konfigurationer skrivs bäst i .config OSGi-konfigurationsformatet eftersom de har stöd för flera rader, vilket är ett undantag till de bästa sätten att använda .cfg.json för att definiera OSGi-konfigurationer.
När du definierar Användare och grupper betraktas bara grupper som en del av programmet och de är en väsentlig del av dess funktion. Du definierar fortfarande användare och grupper för organisation vid körning i AEM. Om ett anpassat arbetsflöde till exempel tilldelar arbete till en namngiven grupp, definierar du den gruppen med hjälp av Repo Init i AEM-programmet. Men om grupperingen bara är organisatorisk, till exempel"Wendy's Team" och"Sean's Team", är de här grupperna bäst definierade och hanterade vid körning i AEM.
scripts fältet, annars fungerar inte references-konfigurationen.Det fullständiga språket för Repo Init-skript finns i dokumentationen för Apache Sling Repo Init.
Databasstrukturpaket repository-structure-package
Kodpaket kräver att konfigurationen för plugin-programmet FileVault Maven konfigureras så att det refererar till en <repositoryStructurePackage> som kräver att strukturella beroenden är korrekta (för att säkerställa att ett kodpaket inte installeras över ett annat). Du kan skapa ett eget databasstrukturpaket för ditt projekt.
Endast obligatoriskt för kodpaket, vilket innebär alla paket som är markerade med <packageType>application</packageType>.
Mer information om hur du skapar ett databasstrukturpaket för programmet finns i Utveckla ett databasstrukturpaket.
Innehållspaket (<packageType>content</packageType>) kräver inte det här databasstrukturpaketet.
Bädda in delpaket i behållarpaketet embeddeds
Innehåll eller kodpaket placeras i en särskild underordnad mapp. Använd FileVault Maven-plugin-programmets <embeddeds>-konfiguration för att rikta in dem mot installation på AEM Author, AEM Publish eller båda. Använd inte <subPackages>-konfigurationen.
Vanliga användningsfall är:
- Behörighetslistor/behörigheter som skiljer sig åt mellan AEM författaranvändare och AEM publiceringsanvändare
- Konfigurationer som används för att stödja aktiviteter endast på AEM författare
- Kod som integreringar med back-office-system som bara krävs för att köras av AEM-författare
Om du vill ange AEM-författare, AEM publicerar eller båda, bäddas paketet in i behållarpaketet all på en speciell mappsökväg i följande format:
/apps/<app-name>-packages/(content|application|container)/install(.author|.publish)?
Bryter ned den här mappstrukturen:
-
Mappen på första nivån måste vara
/apps. -
Mappen på den andra nivån representerar programmet med
-packagesefter mappnamnet. Det finns ofta bara en mapp på andra nivån som alla underpaket är inbäddade i, men hur många mappar på andra nivån som helst kan skapas för att representera programmets bästa logiska struktur:/apps/my-app-packages/apps/my-other-app-packages/apps/vendor-packages
note warning WARNING Delpaketets inbäddade mappar namnges med suffixet -packages. Detta namn garanterar att distributionskoden och innehållspaketen inte distribueras till målmapparna för alla underpaket under/apps/<app-name>/.... På så sätt förhindras destruktiv och cyklisk installation. -
Mappen på den tredje nivån måste vara antingen
application,contentellercontainer- Mappen
applicationinnehåller kodpaket - Mappen
contentinnehåller innehållspaket - Mappen
containerinnehåller alla extra programpaket som kanske inte ingår i AEM-programmet.
Det här mappnamnet motsvarar pakettyperna för paketen som det innehåller.
- Mappen
-
Mappen på den fjärde nivån innehåller underpaketen och måste vara någon av:
installså att du kan installera på både AEM-författare och AEM-publiceringinstall.authorså att du installerar only på AEM-författareninstall.publishså att du installerar only i AEM Publish
Endastinstall.authorochinstall.publishstöds som mål. Andra körningslägen stöds inte.
En distribution som innehåller AEM-författare och publicerar specifika paket kan till exempel se ut så här:
-
all-behållarpaketet bäddar in följande paket för att skapa en enda distributionsartefaktui.appsinbäddad i/apps/my-app-packages/application/installdistribuerar kod till både AEM-författaren och AEM-publiceringui.apps.authorinbäddad i/apps/my-app-packages/application/install.authordistribuerar kod till endast AEM-författareui.contentinbäddat i/apps/my-app-packages/content/installdistribuerar innehåll och konfiguration till både AEM-författaren och AEM-publiceringui.content.publishinbäddad i/apps/my-app-packages/content/install.publishdistribuerar innehåll och konfiguration till enbart AEM-publicering
Behållarpaketets filterdefinition container-package-filter-definition
På grund av inbäddningen av kod- och innehållsunderpaket i behållarpaketet måste de inbäddade målsökvägarna läggas till i behållarprojektets filter.xml. Detta säkerställer att de inbäddade paketen inkluderas i behållarpaketet när de byggs.
Lägg bara till <filter root="/apps/<my-app>-packages"/>-posterna för mappar på andra nivån som innehåller underpaket som ska distribueras.
Bädda in paket från tredje part embedding-3rd-party-packages
Alla paket måste vara tillgängliga via Adobe publika Maven-artefaktdatabas eller en tillgänglig offentlig, refererbar tredjepartsdatabas för Maven-artefakter.
Om tredjepartspaketen finns i Adobe offentliga Maven-artefaktdatabas behövs ingen ytterligare konfiguration för att Adobe Cloud Manager ska kunna lösa artefakterna.
Om tredjepartspaketen finns i en offentlig tredjepartsdatabas för Maven-felaktigheter måste den här databasen registreras i projektets pom.xml och bäddas in enligt metoden som beskrivs ovan.
Tredjepartsprogram/-anslutningar bör bäddas in med dess all-paket som en behållare i projektets behållarpaket (all).
Om du lägger till Maven-beroenden följer standardMaven-rutiner, och inbäddning av tredjepartsartefakter (kod- och innehållspaket) beskrivs ovan.
Paketberoenden mellan ui.apps från ui.content-paket package-dependencies
För att paketen ska kunna installeras på rätt sätt rekommenderar vi att du skapar beroenden mellan paket.
Den allmänna regeln är paket som innehåller muterbart innehåll (ui.content) som ska vara beroende av den oföränderliga koden (ui.apps) som stöder återgivning och användning av det muterbara innehållet.
Ett betydande undantag från den här allmänna regeln är om det oföränderliga kodpaketet (ui.apps eller något annat), only, innehåller OSGi-paket. I så fall ska inget AEM-paket deklarera ett beroende av det. Orsaken är att oföränderliga kodpaket som endast innehåller OSGi-paket inte har registrerats med AEM Package Manager. Alla AEM-paket som är beroende av det är därför inte beroende och kan inte installeras.
De vanligaste mönstren för innehållspaketberoenden är:
Beroenden för enkla distributionspaket simple-deployment-package-dependencies
I det enkla fallet anges att det ui.content-ändringsbara innehållspaketet ska vara beroende av det ui.apps-oföränderliga kodpaketet.
-
allhar inga beroendenui.appshar inga beroendenui.contentär beroende avui.apps
Komplexa distributionspaketberoenden complex-deploxment-package-dependencies
Komplexa driftsättningar bygger vidare på det enkla fallet och ställer in beroenden mellan motsvarande muterbara innehåll och oföränderliga kodpaket. Om det behövs kan beroenden etableras även mellan oföränderliga kodpaket.
-
allhar inga beroendencommon.ui.apps.commonhar inga beroendensite-a.ui.appsär beroende avcommon.ui.appssite-a.ui.contentär beroende avsite-a.ui.appssite-b.ui.appsär beroende avcommon.ui.appssite-b.ui.contentär beroende avsite-b.ui.apps
Lokal utveckling och driftsättning local-development-and-deployment
Projektstrukturerna och organisationen som beskrivs i den här artikeln är fullständigt kompatibla med AEM-instanser för lokal utveckling.
POM XML-kodfragment pom-xml-snippets
Nedan följer Maven pom.xml-konfigurationsfragment som kan läggas till i Maven-projekt för att anpassa sig till ovanstående rekommendationer.
Pakettyper xml-package-types
Kod- och innehållspaket, som distribueras som underpaket, måste deklarera pakettypen application eller content, beroende på vad de innehåller.
Typ av behållarpaket container-package-types
Behållarprojektet all/pom.xml deklarerar inte en <packageType>.
Pakettyper för kod (ej ändringsbar) immutable-package-types
Kodpaket måste ange packageType till application.
I ui.apps/pom.xml deklarerar byggkonfigurationsdirektiven <packageType>application</packageType> för plugin-deklarationen filevault-package-maven-plugin pakettypen.
...
<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>
...
Pakettyper för innehåll (ändringsbart) mutable-package-types
Innehållspaket måste ange packageType till content.
I ui.content/pom.xml deklarerar byggkonfigurationsdirektivet <packageType>content</packageType> för plugin-deklarationen filevault-package-maven-plugin pakettypen.
...
<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>
...
Markera paket för distribution av Adobe Cloud Manager cloud-manager-target
I varje projekt som genererar ett paket, utom för behållarprojektet (all), lägger du till <cloudManagerTarget>none</cloudManagerTarget> i <properties>-konfigurationen för plugin-deklarationen för filevault-package-maven-plugin för att vara säker på att Adobe Cloud Manager inte** distribuerar dem. Behållarpaketet (all) ska vara ett enskilt paket som distribueras via Cloud Manager, vilket i sin tur bäddar in all nödvändig kod och alla nödvändiga innehållspaket.
...
<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 snippet-repo-init
Repo Init-skript som innehåller Repo Init-skript definieras i OSGi-fabrikskonfigurationen RepositoryInitializer via egenskapen scripts. Eftersom du definierar dessa skript i OSGi-konfigurationer kan du enkelt omfång genom att använda körningsläget med hjälp av det vanliga ../config.<runmode>-mappsemantiken.
Eftersom skript vanligtvis är flerradsdeklarationer är det enklare att definiera dem i filen .config än det JSON-baserade .cfg.json-formatet.
/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
"]
OSGi-egenskapen scripts innehåller direktiv enligt definitionen i Apache Slings Repo Init-språk.
Databasstrukturpaket xml-repository-structure-package
I ui.apps/pom.xml och alla andra pom.xml som deklarerar ett kodpaket (<packageType>application</packageType>) lägger du till följande konfiguration av databasstrukturpaket i plugin-programmet FileVault Maven. Du kan skapa ett eget databasstrukturpaket för ditt projekt.
...
<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>
...
Bädda in delpaket i behållarpaketet xml-embeddeds
I all/pom.xml lägger du till följande <embeddeds>-direktiv i plugin-deklarationen för filevault-package-maven-plugin. Kom ihåg att inte använder <subPackages>-konfigurationen. Orsaken är att det inkluderar delpaketen i /etc/packages i stället för /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>
...
Behållarpaketets filterdefinition xml-container-package-filters
I all (filter.xml) för projektet all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml inkluderar alla mappar som innehåller underpaket som ska distribueras: -packages
<filter root="/apps/my-app-packages"/>
Om flera /apps/*-packages används i de inbäddade målen måste alla räknas upp här.
Maven-databaser från tredje part xml-3rd-party-maven-repositories
I reaktorprojektets pom.xml lägger du till eventuella nödvändiga direktiv från tredje part för databasen Maven. Den fullständiga <repository>-konfigurationen bör vara tillgänglig från tredjepartsprovidern för databas.
<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>
Paketberoenden mellan ui.apps från ui.content-paket xml-package-dependencies
I ui.content/pom.xml lägger du till följande <dependencies>-direktiv i plugin-deklarationen för 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>
...
Rensa behållarprojektets målmapp xml-clean-container-package
I all/pom.xml lägger du till plugin-programmet maven-clean-plugin som rensar målkatalogen före en Maven-konstruktion.
<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>