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.

AEM toepassingsimplementaties moeten bestaan uit één AEM. 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.

Mutable versus Immuable Areas of the Repository mutable-vs-immutable

/apps en /libs gebieden van AEM worden beschouwd als onveranderlijk omdat zij niet kunnen worden veranderd (creeer, update, schrapping) na AEM begin (namelijk bij runtime). 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

Oak-indexen (/oak:index) worden beheerd door het AEM as a Cloud Service-implementatieproces. 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 de configuraties maken deel uit van het Pakket van de Code en geen deel van het Pakket van de Inhoud 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

Inhoud-pakketten

Containerpakketten

Extra toepassingspakketten extra-application-packages

Als andere AEM Projecten - die zelf uit hun eigen code en inhoudspakketten bestaan - door de AEM plaatsing worden gebruikt, zouden hun containerpakketten in het pakket van het project all moeten worden ingebed.

Bijvoorbeeld, zou een AEM project dat twee verkoper AEM toepassingen omvat als kunnen kijken:

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

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

Standaard worden alle door de Maven-build geproduceerde pakketten door Adobe Cloud Manager geoogst. 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 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 tijdcode bestaan 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. Als dusdanig, kunnen zij impliciet door looppaswijze worden gericht, die voor verschillen tussen AEM Auteur en AEM de manuscripten van de Repo van de Diensten van Publish, of zelfs tussen milieu's (Dev, Stadium, en Prod) toestaat.

Repo Init OSGi vormt best geschreven in het .config OSGi configuratieformaataangezien zij multi-lines steunen, die een uitzondering op de beste praktijken is om .cfg.json te gebruiken om configuraties te bepalen OSGi.

Wanneer het bepalen van Gebruikers, en Groepen, slechts worden de groepen beschouwd als deel van de toepassing, en integraal aan zijn functie. U definieert bij uitvoering nog steeds Organisatiegebruikers en -groepen in AEM. Als een aangepaste workflow bijvoorbeeld werk toewijst aan een benoemde groep, definieert u die groep als repo-item in de AEM toepassing. Nochtans, als de Groepering slechts organisatorisch, zoals "Team van Wendy"en "Team van Sean"is, worden deze groepen het best bepaald en geleid bij runtime in AEM.

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

Structuurpakket 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 projecttot 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 map "side-car" geplaatst en kunnen worden geïnstalleerd op AEM auteur, AEM publicatie of beide via de configuratie <embeddeds> van de FileVault Maven-plug-in. Gebruik de <subPackages> -configuratie niet.

Veelvoorkomende gebruiksgevallen zijn:

Als u AEM auteur als doel wilt instellen, AEM publiceert of beide, wordt het pakket 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 de openbare Geweven bewaarplaats van het Artefact van de Adobeof een toegankelijk openbaar, van verwijzingen voorzien derdeGeproduceerde artefactbewaarplaats beschikbaar zijn.

Als de derdepakketten in openbare Maven artefactbewaarplaats van de Adobe 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 🔗.

Afhankelijkheden van pakketten tussen de ui.apps en ui.content Pakketten package-dependencies

Om een correcte installatie van de pakketten te verzekeren, wordt het geadviseerd 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 AEM pakket een afhankelijkheid van het moeten verklaren. De reden is omdat de onveranderlijke codepakketten die slechts OSGi bundels bevatten, niet met AEM Manager van het Pakketworden geregistreerd. Daarom heeft om het even welk AEM pakket dat van het afhangt een ontevreden gebiedsdeel en niet om te installeren.

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 - compatibele lokale ontwikkeling AEM instanties.

XML-fragmenten voor POM 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>.

Code (Immuable) pakkettypen 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>
    ...

Inhoud (Mutable) Pakkettypen 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 genereert, behalve voor het containerproject (all), voegt u <cloudManagerTarget>none</cloudManagerTarget> aan de <properties>-configuratie van de declaratie van de invoegtoepassing filevault-package-maven-plugin toe om ervoor te zorgen dat deze niet door Adobe Cloud Manager worden geïmplementeerd. 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 scripts gedefinieerd in de RepositoryInitializer OSGi-fabrieksconfiguratie. Omdat deze manuscripten binnen configuraties OSGi worden bepaald, kunnen zij gemakkelijk bereikbaar zijn 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 Apacheworden bepaald.

Structuurpakket 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 projecttot 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 /apps/my-app-packages/<application|content|container>/install(.author|.publish)? , maar in /etc/packages 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.

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

Afhankelijkheden van pakketten tussen de ui.apps en ui.content Pakketten 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>
...

De doelmap van het containerproject opschonen 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