AEM-projectstructuur

In dit artikel worden de wijzigingen beschreven die nodig zijn om projecten van Adobe Experience Manager Maven as a Cloud Service AEM te maken 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 content en code, wat betekent dat er één inhoudspakket is kan implementeren voor beide /apps en runtime-schrijfbare gebieden (bijvoorbeeld /content, /conf, /homeof iets anders /apps) van de gegevensopslagruimte. 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

De /apps en /libs AEM onaantastbaar omdat deze niet kunnen worden gewijzigd (maken, bijwerken, verwijderen) nadat AEM is gestart (dus bij uitvoering). Elke poging om een onveranderbaar gebied tijdens runtime te wijzigen, mislukt.

Alle andere gegevens in de opslagplaats, /content, /conf, /var, /etc, /oak:index, /system, /tmp, enzovoort, zijn allemaal veranderlijk gebieden, wat betekent dat deze tijdens runtime kunnen worden gewijzigd.

eiken indexen oak-indexes

Eik-indexen (/oak:index) worden beheerd door het AEM as a Cloud Service implementatieproces. De reden hiervoor is dat de Cloud Manager moet wachten tot een nieuwe index is geïmplementeerd en volledig opnieuw is gedexeerd voordat wordt overgeschakeld naar de nieuwe codeafbeelding.

Daarom, hoewel de indexen van de eiken in 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 uit 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-bundels

Inhoudspakketten

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 project moeten worden ingebed all pakket.

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.

Zie voor meer informatie Apache Jackrabbit FileVault - PakketMaven Plugin-documentatie, Apache Jackrabbit-pakkettypenen de FileVault Maven-configuratiefragment hieronder.

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

Standaard verzamelt Adobe Cloud Manager alle pakketten die door de Maven-build zijn gemaakt. Maar omdat de container (all) is het unieke implementatieartefact dat alle code en inhoudspakketten bevat. alleen de container (all) wordt geïmplementeerd. 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.

Terwijl de manuscripten van het Begin van de Repo zelf in ui.config Als scripts gebruiken, kunnen en moeten ze worden gebruikt om de volgende veranderbare structuren te definiëren:

Scripts voor herhalen van indelingen worden opgeslagen als scripts vermeldingen van RepositoryInitializer OSGi-fabrieksconfiguraties. Als zodanig kunnen ze impliciet worden aangewezen door de uitvoermodus, zodat er verschillen zijn tussen de scripts Repo Init van AEM-auteur en AEM-publicatieservices, of zelfs tussen omgevingen (Dev, Stage en Prod).

Reparatie-Init OSGi-configuraties worden het beste geschreven in het dialoogvenster .config OSGi-configuratie aangezien zij multilines steunen, die een uitzondering op de beste praktijken van het gebruiken is .cfg.json om OSGi configuraties te bepalen.

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 scripts van Repo Init is beschikbaar op het tabblad Apache Sling Repo Init-documentatie.

Structuurpakket opslagplaats repository-structure-package

Codepakketten vereisen dat de configuratie van de FileVault Maven-plug-in wordt geconfigureerd voor verwijzing naar een <repositoryStructurePackage> die de juistheid van structurele gebiedsdelen afdwingt (om ervoor te zorgen dat één codepakket niet over een andere installeert). U kunt zelf een opslagstructuurpakket voor uw project maken.

Alleen vereist voor codepakketten: pakketten gemarkeerd met <packageType>application</packageType>.

Ga voor meer informatie over het maken van een opslagplaatsstructuurpakket voor uw toepassing naar Een structuurpakket voor opslagplaats ontwikkelen.

Inhoudspakketten (<packageType>content</packageType>) niet vereist dit 'repository structure Package'.

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 met de FileVault Maven-plug-in <embeddeds> configuratie. Gebruik de <subPackages> configuratie.

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 map-locatie, 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

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

Voeg eenvoudig de <filter root="/apps/<my-app>-packages"/> vermeldingen voor mappen op het tweede niveau die subpakketten bevatten die moeten worden geïmplementeerd.

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

Alle pakketten moeten beschikbaar zijn via de Adobe of een toegankelijke openbare gegevensopslagruimte met verwijzing naar derde partijen.

Als de pakketten van derden zich bevinden in Adobe, is er geen verdere configuratie nodig voor Adobe Cloud Manager om de artefacten op te lossen.

Als de pakketten van derden zich in een openbare gegevensopslagruimte van derden voor effecten, moet deze opslagplaats in het project worden geregistreerd pom.xml en ingesloten volgens de methode hierboven geschetst.

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

Het toevoegen van Geweven gebiedsdelen volgt standaard Geweven praktijken, en het inbedden van derdeartefacten (code en inhoudspakketten) zijn hierboven geschetst.

Pakketafhankelijke onderdelen tussen de ui.apps van 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 dat pakketten met een veranderbaar gehalte (ui.content) moet afhankelijk zijn van de onveranderlijke code (ui.apps) die het renderen en gebruiken van de veranderbare inhoud ondersteunt.

Een opmerkelijke uitzondering op deze algemene regel is wanneer het onveranderlijke codepakket (ui.apps of andere) alleen bevat OSGi-bundels. Zo ja, dan zou geen AEM pakket een afhankelijkheid van het moeten verklaren. De reden hiervoor is dat onveranderlijke codepakketten alleen bevatten OSGi-bundels, zijn niet geregistreerd bij AEM Pakketbeheer. Daarom heeft om het even welk AEM pakket dat van het afhangt een ontevreden gebiedsdeel en niet om te installeren.

De gemeenschappelijke patronen voor tevreden pakketgebiedsdelen zijn:

Eenvoudige implementatiepakketafhankelijkheden simple-deployment-package-dependencies

Met de eenvoudige optie stelt u de ui.content veranderbaar inhoudspakket om van ui.apps onveranderlijk codepakket.

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 in dit artikel geschetste projectstructuren en -organisatie zijn: volledig compatibel lokale ontwikkeling AEM instanties.

XML-fragmenten voor POM pom-xml-snippets

Het volgende wordt gemaakt pom.xml configuratiefragmenten die aan Geweven projecten kunnen worden toegevoegd om aan de bovengenoemde aanbevelingen te richten.

Pakkettypen xml-package-types

Code- en inhoudspakketten die als subpakketten worden geïmplementeerd, moeten een pakkettype declareren van toepassing of content, afhankelijk van wat ze bevatten.

Containerpakkettypen container-package-types

De container all/pom.xml project niet verklaren <packageType>.

Code (Immuable) pakkettypen immutable-package-types

Codepakketten moeten hun packageType tot application.

In de ui.apps/pom.xmlde <packageType>application</packageType> stelt configuratierichtlijnen van de filevault-package-maven-plugin de insteekmoduledeclaratie declareert 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 tot content.

In de ui.content/pom.xmlde <packageType>content</packageType> bouwstijlrichtlijn van filevault-package-maven-plugin de insteekmoduledeclaratie declareert 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.content</name>
        <packageType>content</packageType>
        <accessControlHandling>merge</accessControlHandling>
        <properties>
          <cloudManagerTarget>none</cloudManagerTarget>
        </properties>
      </configuration>
    </plugin>
    ...

Pakketten markeren voor implementatie van Adobe Cloud Manager 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. De container (all) moet het unieke 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, worden gedefinieerd in het dialoogvenster RepositoryInitializer OSGi-fabrieksconfiguratie via de scripts eigenschap. Omdat deze manuscripten binnen configuraties OSGi worden bepaald, kunnen zij gemakkelijk bereikbaar door looppaswijze gebruikend het gebruikelijke zijn ../config.<runmode> mapsemantiek.

Aangezien scripts doorgaans een declaratie van meerdere regels zijn, is het eenvoudiger om deze te definiëren in het dialoogvenster .config bestand, dan op JSON gebaseerd .cfg.json gebruiken.

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

De scripts OSGi-eigenschap bevat instructies zoals gedefinieerd door de Repo Init-taal van Apache Sling.

Structuurpakket opslagplaats xml-repository-structure-package

In de ui.apps/pom.xml en andere pom.xml dat een codepakket declareert (<packageType>application</packageType>), voegt u de volgende configuratie voor het structuurpakket van de repository toe aan de FileVault Maven-plug-in. U kunt zelf een opslagstructuurpakket voor uw project maken.

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

In de all/pom.xmlvoegt u het volgende toe <embeddeds> aan de filevault-package-maven-plugin insteekmoduledeclaratie. Onthoud, niet gebruiken <subPackages> configuratie. De reden hiervoor is dat de subpakketten in /etc/packages eerder dan /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>
...

Filterdefinitie van containerpakket xml-container-package-filters

In de all project filter.xml (all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml), include alle -packages mappen met subpakketten die moeten worden geïmplementeerd:

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

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

Geplaatste opslagplaatsen van derden xml-3rd-party-maven-repositories

In het reactorproject pom.xmlvoegt u de benodigde instructies voor openbare gegevensopslagruimte van derden toe. De volledige <repository> De 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>

Pakketafhankelijke onderdelen tussen de ui.apps van ui.content Pakketten xml-package-dependencies

In de ui.content/pom.xmlvoegt u het volgende toe <dependencies> aan de filevault-package-maven-plugin insteekmoduledeclaratie.

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

In de all/pom.xml, voegt u de maven-clean-plugin insteekmodule waarmee de doelmap wordt gewist voordat een Maven-build wordt 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