AEM-projectstructuur

In dit artikel worden de wijzigingen beschreven die nodig zijn om Adobe Experience Manager Maven-projecten compatibel te maken met AEM as a Cloud Service, door ervoor te zorgen dat ze de opsplitsing van muteerbare en onveranderlijke inhoud respecteren. Ook, worden de gebiedsdelen gevestigd om niet-strijdige, deterministische plaatsingen tot stand te brengen, en zij worden verpakt in een plaatsbare structuur.

Implementaties van AEM-toepassingen moeten uit één AEM-pakket bestaan. Dit pakket moet op zijn beurt subpakketten bevatten die alles bevatten wat door de toepassing wordt vereist om te functioneren, met inbegrip van code, configuratie, en om het even welke ondersteunende basislijninhoud.

AEM vereist een scheiding van inhoud en code, wat één enkel inhoudspakket betekent kan niet aan zowel opstellen /apps en runtime-schrijfbare gebieden (bijvoorbeeld, /content, /conf, /home, of om het even wat niet /apps) van de bewaarplaats. In plaats daarvan moet de applicatie code en content scheiden in afzonderlijke pakketten voor implementatie in AEM.

De pakketstructuur die in dit document wordt beschreven, is compatibel met zowel lokale ontwikkelingsimplementaties als AEM Cloud Service-implementaties.

Mabellen versus onveranderlijke gebieden van de gegevensopslagruimte mutable-vs-immutable

/apps en /libs gebieden van AEM zijn onveranderlijk. Nadat AEM is gestart, kunt u tijdens runtime geen inhoud in deze gebieden meer maken, bijwerken of verwijderen. Elke poging om een onveranderbaar gebied tijdens runtime te wijzigen, mislukt.

Al het andere in de bewaarplaats, /content, /conf, /var, /etc, /oak:index, /system, /tmp, etc., zijn alle veranderbare gebieden, betekenend zij kunnen bij runtime worden veranderd.

Oak-indexen oak-indexes

Het AEM as a Cloud Service-implementatieproces beheert Oak-indexen (/oak:index). De reden hiervoor is dat de Cloud Manager moet wachten totdat een nieuwe index wordt geïmplementeerd en volledig opnieuw is geordend voordat wordt overgeschakeld naar de nieuwe codeafbeelding.

Daarom, hoewel de indexen van Oak bij runtime veranderbaar zijn, moeten zij als code worden opgesteld zodat zij kunnen worden geïnstalleerd alvorens om het even welke veranderlijke pakketten worden geïnstalleerd. Daarom /oak:index vormen de configuraties deel van het codepakket en geen deel van het inhoudspakket ​ zoals hieronder beschreven ​.

Aanbevolen pakketstructuur recommended-package-structure

Dit diagram verstrekt een overzicht van de geadviseerde projectstructuur en pakketplaatsingsartefacten.

De aanbevolen implementatiestructuur voor toepassingen is als volgt:

Codepakketten/OSGi-pakketten

Inhoudspakketten

Containerpakketten

Extra toepassingspakketten extra-application-packages

Als andere AEM-projecten - die zelf uit hun eigen code en inhoudspakketten bestaan - door de AEM-implementatie worden gebruikt, moeten hun containerpakketten in het all -pakket van het project worden ingesloten.

Een AEM-project dat twee AEM-toepassingen van leveranciers bevat, ziet er bijvoorbeeld als volgt uit:

Pakkettypen package-types

Pakketten moeten worden gemarkeerd met het opgegeven pakkettype. De types van pakket helpen het doel en de plaatsing van een pakket verduidelijken.

Voor meer informatie zie ​ Apache Jackrabbit FileVault - Pakket Maven de documentatie van de Insteekmodule ​, ​ de Types van Pakket van het Pakket Apache Jackrabbit ​, en het ​ FileVault Maven configuratiefragment ​ hieronder.

Pakketten markeren voor implementatie door Adobe Cloud Manager marking-packages-for-deployment-by-adoube-cloud-manager

Adobe Cloud Manager verzamelt standaard alle pakketten die door de Maven-build worden geproduceerd. Nochtans, omdat het container (all) pakket het unieke plaatsingsartefact is dat alle code en inhoudspakketten bevat, moet u verzekeren slechts het container (all) pakket wordt opgesteld. Om dit te garanderen moeten andere pakketten die de Maven-build genereert, zijn gemarkeerd met de configuratie voor de FileVault Content Package Maven-invoegtoepassing van <properties><cloudManagerTarget>none</cloudManageTarget></properties>.

Reparatie-item repo-init

Repo Init verstrekt instructies, of manuscripten, die structuren JCR, die zich van gemeenschappelijke knoopstructuren zoals omslagbomen, aan gebruikers, de dienstgebruiker, groepen, en ACL definitie uitstrekken bepalen.

De belangrijkste voordelen van Repo Init zijn dat zij impliciete toestemmingen hebben om alle acties uit te voeren die door hun manuscripten worden bepaald. En, worden dergelijke manuscripten aangehaald vroeg in de plaatsingslevenscyclus, die ervoor zorgt dat alle vereiste structuren JCR tegen de tijd bestaan de code in werking wordt gesteld.

Hoewel de manuscripten van de Inzet van de Repo in het ui.config project als manuscripten leven, kunnen en moeten zij worden gebruikt om de volgende veranderbare structuren te bepalen:

Scripts voor herhalingsindelingen worden opgeslagen als scripts -items van RepositoryInitializer OSGi-fabrieksconfiguraties. De uitvoermodus kan deze impliciet als doel instellen. Met deze functie kunt u scripts voor het instellen van een repo-id onderscheiden tussen AEM Author en AEM Publish Services, of zelfs tussen Dev-, Stage- en Prod-omgevingen.

De configuraties van het Begin van de herhaling OSGi kunnen het best in het .config OSGi- configuratieformaat ​ worden geschreven aangezien zij multi-lines steunen, die een uitzondering op de beste praktijken is om .cfg.json te gebruiken om configuraties te bepalen OSGi ​.

Wanneer u Gebruikers en groepen definieert, worden alleen groepen beschouwd als onderdeel van de toepassing en integraal onderdeel van de functie. Bij uitvoering in AEM definieert u nog steeds Organisatiegebruikers en -groepen. Als een aangepaste workflow bijvoorbeeld werk toewijst aan een benoemde groep, definieert u die groep als repo-item in de AEM-toepassing. Als de Groepering echter louter organisatorisch is, zoals "Wendy's Team" en "Sean's Team", kunnen deze groepen het best worden gedefinieerd en beheerd bij uitvoering in AEM.

De volledige woordenlijst voor de manuscripten van het Begin van de Repo is beschikbaar in de ​ Apache Sling documentatie van het Begin van de Repo ​.

Structuurpakket voor opslagplaats repository-structure-package

Codepakketten vereisen dat de configuratie van de FileVault Maven-plug-in wordt geconfigureerd om te verwijzen naar een <repositoryStructurePackage> die de juistheid van structurele afhankelijkheden afdwingt (om ervoor te zorgen dat een codepakket niet boven een ander codepakket wordt geïnstalleerd). U kunt ​ uw eigen de structuurpakket van de bewaarplaats voor uw project ​ tot stand brengen.

slechts vereist voor de pakketten van de Code, betekenend om het even welk Pakket duidelijk met <packageType>application</packageType>.

Leren hoe te om een pakket van de gegevensopslagstructuur voor uw toepassing tot stand te brengen, zie ​ een Pakket van de Structuur van de Opslag ontwikkelen ​.

De pakketten van de inhoud (<packageType>content</packageType>) vereisen niet dit pakket van de bewaarplaatsstructuur.

Subpakketten insluiten in het containerpakket embeddeds

Inhoud- of codepakketten worden in een speciale secundaire map geplaatst. Gebruik de configuratie <embeddeds> van de plug-in FileVault Maven om deze als doel in te stellen voor installatie op AEM Author, AEM Publish of beide. Gebruik de <subPackages> -configuratie niet.

Veelvoorkomende gebruiksgevallen zijn:

Als u de AEM-auteur als doel wilt instellen, publiceert AEM of beide het pakket wordt ingesloten in het all -containerpakket in een speciale maplocatie, in de volgende indeling:

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

Deze mapstructuur indelen:

Een implementatie die AEM-auteur bevat en specifieke pakketten publiceert, kan er bijvoorbeeld als volgt uitzien:

Filterdefinitie van Containerpakket container-package-filter-definition

Wegens het inbedden van de code en inhoudsubpakketten in het containerpakket, moeten de ingebedde doelwegen aan het containerproject filter.xml worden toegevoegd. Dit zorgt ervoor dat de ingesloten pakketten bij het maken in het containerpakket worden opgenomen.

Voeg gewoon de <filter root="/apps/<my-app>-packages"/> -items toe voor mappen op het tweede niveau die subpakketten bevatten die u wilt implementeren.

Pakketten van derden insluiten embedding-3rd-party-packages

Alle pakketten moeten via ​ Adobe openbaar Maven artefactbewaarplaats ​ of een toegankelijk openbaar, van verwijzingen voorzien derdeGeproduceerde artefactbewaarplaats beschikbaar zijn.

Als de derdepakketten in Adobe openbare Maven artefactbewaarplaats zijn, is geen verdere configuratie nodig voor Adobe Cloud Manager om de artefacten op te lossen.

Als de derdepakketten in a openbare derde Geleide artefactbewaarplaats zijn, moet deze bewaarplaats in het project pom.xml en ingebed na de hierboven geschetste methode ​ ​ worden geregistreerd.

De toepassing/de schakelaars van de derde zouden moeten worden ingebed gebruikend zijn all pakket als container in de container van uw project (all) pakket.

Toevoegend Geweven gebiedsdelen volgen standaard Geweven praktijken, en het inbedden van derdeartefacten (code en inhoudspakketten) worden hierboven geschetst ​ ​.

Pakketafhankelijkheden tussen de pakketten ui.apps van ui.content package-dependencies

Om een correcte installatie van de pakketten te verzekeren, wordt geadviseerd dat interpackage gebiedsdelen worden gevestigd.

De algemene regel is pakketten die veranderbare inhoud (ui.content) bevatten zou van de onveranderlijke code (ui.apps) moeten afhangen die het teruggeven en het gebruik van de veranderlijke inhoud steunt.

Een opmerkelijke uitzondering op deze algemene regel is als het onveranderlijke codepakket (ui.apps of een ander), slechts OSGi bundels bevat. Zo ja, dan zou geen enkel AEM-pakket ervan afhankelijk moeten zijn. De reden is omdat de onveranderlijke codepakketten die slechts OSGi bundels bevatten, niet met de Manager van het Pakket van AEM ​ ​ worden geregistreerd. Daarom heeft elk AEM-pakket dat hiervan afhankelijk is een onbevredigende afhankelijkheid en kan het niet worden geïnstalleerd.

De gemeenschappelijke patronen voor de gebiedsdelen van het inhoudspakket zijn:

Eenvoudige implementatiepakketafhankelijkheden simple-deployment-package-dependencies

Met het eenvoudige hoofdlettergebruik wordt het ui.content veranderbare inhoudspakket zo ingesteld dat het afhankelijk is van het ui.apps -pakket voor onveranderlijke code.

Complexe implementatiepakketafhankelijkheden complex-deploxment-package-dependencies

De complexe plaatsingen breiden zich op het eenvoudige geval uit en plaatsen gebiedsdelen tussen de overeenkomstige veranderlijke inhoud en de onveranderlijke codepakketten. Zoals vereist, kunnen de gebiedsdelen ook tussen onveranderlijke codepakketten worden gevestigd.

Lokale ontwikkeling en implementatie local-development-and-deployment

De projectstructuren en organisatie die in dit artikel worden geschetst zijn volledig compatibel met lokale instanties van AEM van de ontwikkelings.

POM XML-fragmenten pom-xml-snippets

Hier volgt een overzicht van pom.xml -configuratiefragmenten die kunnen worden toegevoegd aan Maven-projecten om deze uit te lijnen op de bovenstaande aanbevelingen.

Pakkettypen xml-package-types

De pakketten van de code en van de inhoud, die als subpakketten worden opgesteld, moeten een pakkettype van toepassing of inhoud verklaren, afhankelijk van wat zij bevatten.

Containerpakkettypen container-package-types

Het container all/pom.xml project verklaart niet a <packageType>.

Typen codepakketten (Immuable) immutable-package-types

Codepakketten moeten hun packageType instellen op application .

In de ui.apps/pom.xml -instructies declareert de <packageType>application</packageType> build-configuratieinstructies van de plug-in filevault-package-maven-plugin het pakkettype.

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

Typen inhoudspakketten (Mutable) mutable-package-types

Inhoudspakketten moeten hun packageType instellen op content .

In de ui.content/pom.xml , verklaart de <packageType>content</packageType> bouwstijlconfiguratierichtlijn van de filevault-package-maven-plugin plugin verklaring zijn pakkettype.

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

Pakketten markeren voor Adobe Cloud Manager-implementatie cloud-manager-target

In elk project dat een Pakket produceert, behalve voor het container (all) project, voeg <cloudManagerTarget>none</cloudManagerTarget> aan de <properties> configuratie van de filevault-package-maven-plugin stop-in verklaring toe om ervoor te zorgen dat Adobe Cloud Manager hen niet** opstelt. Het containerpakket (all) moet het enkelvoudige pakket zijn dat via Cloud Manager wordt geïmplementeerd en dat op zijn beurt alle vereiste code- en inhoudspakketten insluit.

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

Reparatie-item snippet-repo-init

Scripts voor Repo Init die de scripts voor Repo Init bevatten, zijn via de eigenschap RepositoryInitializer gedefinieerd in de scripts OSGi-fabrieksconfiguratie. Omdat u deze manuscripten binnen configuraties OSGi bepaalt, kunt u hen gemakkelijk door wijze in werking te stellen gebruikend de gebruikelijke ../config.<runmode> omslagsemantiek.

Aangezien scripts doorgaans een declaratie van meerdere regels zijn, is het eenvoudiger om ze in het .config -bestand te definiëren dan in de op JSON gebaseerde .cfg.json -indeling.

/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
"]

Het scripts bezit OSGi bevat richtlijnen zoals die door de ​ Reparatie van de Schaal van Apache ​ worden bepaald.

Structuurpakket voor opslagplaats xml-repository-structure-package

Voeg in de ui.apps/pom.xml en elke andere pom.xml die een codepakket declareert ( <packageType>application</packageType> ) de volgende configuratie van het opslagstructuurpakket toe aan de FileVault Maven-plug-in. U kunt ​ uw eigen de structuurpakket van de bewaarplaats voor uw project ​ tot stand brengen.

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

Subpakketten insluiten in het containerpakket xml-embeddeds

Voeg in de all/pom.xml de volgende <embeddeds> -instructies toe aan de declaratie van de filevault-package-maven-plugin -invoegtoepassing. Herinner me, gebruikt niet de <subPackages> configuratie. De reden hiervoor is dat de subpakketten niet in /etc/packages , maar in /apps/my-app-packages/<application|content|container>/install(.author|.publish)? worden opgenomen.

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

Filterdefinitie van Containerpakket xml-container-package-filters

In all project filter.xml (all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml), omvat om het even welke -packages omslagen die subpakketten bevatten om op te stellen:

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

Als er meerdere /apps/*-packages worden gebruikt in de ingesloten doelen, moeten ze allemaal hier worden opgesomd.

GeMaven repositories van derden xml-3rd-party-maven-repositories

Voeg in de pom.xml -instructies van het reactorproject de benodigde instructies van derden voor openbare opslag Maven toe. De volledige <repository> -configuratie moet beschikbaar zijn bij de externe opslagprovider.

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

Pakketafhankelijkheden tussen de pakketten ui.apps van ui.content xml-package-dependencies

Voeg in de ui.content/pom.xml de volgende <dependencies> -instructies toe aan de declaratie van de filevault-package-maven-plugin -invoegtoepassing.

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

Reinig de doelmap van het containerproject xml-clean-container-package

Voeg in all/pom.xml de plug-in maven-clean-plugin toe die de doelmap wist voordat een Maven-build werd gemaakt.

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

Aanvullende bronnen additional-resources