Estructura del proyecto AEM

Este artículo describe los cambios necesarios para que los proyectos de Adobe Experience Manager AEM Maven sean compatibles en términos as a Cloud Service, asegurándose de que respetan la división del contenido mutable e inmutable. Además, las dependencias se establecen para crear implementaciones determinísticas y no conflictivas, y se empaquetan en una estructura implementable.

AEM AEM Las implementaciones de aplicaciones de la aplicación deben estar compuestas por un solo paquete de la aplicación A su vez, este paquete debe contener subpaquetes que incluyan todo lo necesario para que la aplicación funcione, incluido el código, la configuración y cualquier contenido de línea de base de soporte.

AEM La requiere una separación de content y código, lo que significa un paquete de contenido único no puede implementar en ambos /apps y áreas de tiempo de ejecución (por ejemplo, /content, /conf, /home, o cualquier cosa que no /apps) del repositorio. En su lugar, la aplicación debe separar el código y el contenido en paquetes discretos para su implementación en AEM.

La estructura del paquete descrita en este documento es compatible tanto con las implementaciones de desarrollo local, como con las implementaciones de AEM Cloud Service.

Áreas mutables e inmutables del repositorio mutable-vs-immutable

El /apps y /libs AEM se consideran las áreas de la inmutable AEM porque no se pueden cambiar (crear, actualizar, eliminar) después de iniciarse el inicio de la (es decir, durante la ejecución). Cualquier intento de cambiar un área inmutable durante la ejecución falla.

Todo lo demás en el repositorio, /content, /conf, /var, /etc, /oak:index, /system, /tmp, etc., son todos mutable , lo que significa que se pueden cambiar durante la ejecución.

Índices Oak oak-indexes

Índices Oak (/oak:indexAEM ) se gestionan mediante el proceso de implementación as a Cloud Service de la. El motivo es que Cloud Manager debe esperar hasta que se implemente cualquier nuevo índice y se vuelva a indexar completamente antes de cambiar a la nueva imagen de código.

Por este motivo, aunque los índices Oak son mutables en tiempo de ejecución, deben implementarse como código para que se puedan instalar antes de instalar cualquier paquete mutable. Por lo tanto /oak:index Las configuraciones de forman parte del paquete de código y no del paquete de contenido como se describe a continuación.

Estructura del paquete recomendado recommended-package-structure

Este diagrama proporciona información general sobre la estructura del proyecto recomendada y los artefactos de implementación de paquetes.

La estructura de implementación de la aplicación recomendada es la siguiente:

Paquetes de código/paquetes OSGi

Paquetes de contenido

Paquetes de contenedor

Paquetes de aplicaciones adicionales extra-application-packages

AEM AEM Si la implementación utiliza otros proyectos de, que a su vez están compuestos por su propio código y paquetes de contenido, los paquetes de contenedores deben incrustarse en los paquetes de contenido del proyecto all paquete.

AEM AEM Por ejemplo, un proyecto de que incluya dos aplicaciones de proveedor puede tener un aspecto similar al siguiente:

Tipos de paquetes package-types

Los paquetes deben marcarse con el tipo de paquete declarado. Los tipos de paquete ayudan a aclarar el propósito y la implementación de un paquete.

Para obtener más información, consulte Apache Jackrabbit FileVault: documentación del complemento Maven del paquete, Tipos de paquetes de Apache Jackrabbit, y el Fragmento de configuración de FileVault Maven más abajo.

Marcado de paquetes para su implementación mediante Adobe Cloud Manager marking-packages-for-deployment-by-adoube-cloud-manager

De forma predeterminada, Adobe Cloud Manager obtiene todos los paquetes producidos por la compilación de Maven. Sin embargo, debido a que el contenedor (all) es el único artefacto de implementación que contiene todos los paquetes de contenido y código. Debe asegurarse de que solamente el contenedor (all) se haya implementado el paquete. Para garantizar esto, otros paquetes que genera la compilación de Maven deben marcarse con la configuración del complemento Maven del paquete de contenido de FileVault <properties><cloudManagerTarget>none</cloudManageTarget></properties>.

Inicio de repo repo-init

Repo Init proporciona instrucciones, o scripts, que definen estructuras JCR, que van desde estructuras de nodos comunes como árboles de carpetas, hasta usuarios, usuarios de servicio, grupos y definición de ACL.

Las ventajas clave de Repo Init son que tienen permisos implícitos para realizar todas las acciones definidas por sus scripts. Además, estos scripts se invocan al principio del ciclo vital de la implementación, lo que garantiza que todas las estructuras JCR necesarias existan antes de que se ejecute el código.

Mientras que los scripts de inicio de repo se activan en la variable ui.config proyecto como secuencias de comandos, se pueden y se deben utilizar para definir las siguientes estructuras mutables:

Los scripts de inicio de repo se almacenan como scripts entradas de RepositoryInitializer Configuraciones de fábrica de OSGi. Como tal, se pueden dirigir implícitamente al modo de ejecución, lo que permite diferencias entre los scripts de inicio de repositorios de AEM Author y AEM Publish Services, o incluso entre entornos (Desarrollo, Ensayo y Producción).

Las configuraciones OSGi de inicio de repo se escriben mejor en la variable .config Formato de configuración OSGi ya que admiten varias líneas, lo que supone una excepción a las prácticas recomendadas de uso de .cfg.json para definir las configuraciones de OSGi.

Al definir Usuarios y Grupos, solo los grupos se consideran parte de la aplicación y parte integral de su función. AEM Aún puede definir Usuarios y grupos de organización durante la ejecución de la aplicación de en el tiempo de ejecución de la. AEM Por ejemplo, si un flujo de trabajo personalizado asigna trabajo a un grupo con nombre, defina ese grupo mediante Repo Init en la aplicación de la. AEM Sin embargo, si la Agrupación es meramente organizativa, como "Equipo de Wendy" y "Equipo de Sean", estos grupos se definen y administran mejor durante la ejecución en el tiempo de ejecución de la.

El vocabulario completo para los scripts de inicio de repo está disponible en la Documentación de inicio del repositorio de Apache Sling.

Paquete de estructura de repositorio repository-structure-package

Los paquetes de código requieren configurar la configuración del complemento FileVault Maven para hacer referencia a un <repositoryStructurePackage> que exige la corrección de las dependencias estructurales (para garantizar que un paquete de código no se instale sobre otro). Puede cree su propio paquete de estructura de repositorio para el proyecto.

Solo obligatorio para paquetes de código, es decir, cualquier paquete marcado con <packageType>application</packageType>.

Para obtener información sobre cómo crear un paquete de estructura de repositorio para la aplicación, consulte Desarrollo de un paquete de estructura de repositorio.

Paquetes de contenido (<packageType>content</packageType>) no requiere este paquete de estructura de repositorio.

Incrustación de subpaquetes en el paquete de contenedor embeddeds

AEM AEM Los paquetes de contenido o código se colocan en una carpeta especial "side-car" y se pueden segmentar para su instalación en los programas de autor, publicación o ambos, mediante el complemento de Maven de FileVault <embeddeds> configuración. No use el <subPackages> configuración.

Los casos de uso comunes incluyen:

AEM AEM Para segmentar a los autores de la, las publicaciones o ambas, el paquete está incrustado en all paquete de contenedor en una ubicación de carpeta especial, con el siguiente formato:

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

Desglose de esta estructura de carpetas:

AEM Por ejemplo, una implementación que contenga paquetes específicos de autor y publicación de la aplicación puede tener el siguiente aspecto:

Definición del filtro del paquete del contenedor container-package-filter-definition

Debido a la incrustación de los subpaquetes de código y contenido en el paquete contenedor, las rutas de destino incrustadas deben agregarse al proyecto contenedor filter.xml. Al hacerlo, se garantiza que los paquetes incrustados se incluyan en el paquete contenedor cuando se creen.

Simplemente añada el <filter root="/apps/<my-app>-packages"/> entradas para cualquier carpeta de segundo nivel que contenga subpaquetes para implementar.

Incrustación de paquetes de terceros embedding-3rd-party-packages

Todos los paquetes deben estar disponibles a través de la Repositorio de artefactos Maven públicos de Adobe o un repositorio de artefactos Maven público y referenciable de terceros.

Si los paquetes de terceros están en Repositorio de artefactos Maven públicos de Adobe Sin embargo, no se necesita ninguna configuración adicional para que Adobe Cloud Manager resuelva los artefactos.

Si los paquetes de terceros están en un repositorio de artefactos Maven de terceros públicos, este repositorio debe estar registrado en el pom.xml e incrustado siguiendo el método descrito anteriormente.

Los conectores/aplicaciones de terceros deben incrustarse con su all como contenedor en el contenedor de su proyecto (all) paquete.

La adición de dependencias Maven sigue las prácticas estándar de Maven y la incrustación de artefactos de terceros (paquetes de contenido y código) son descrito anteriormente.

Dependencias del paquete entre ui.apps de ui.content Paquetes package-dependencies

Para garantizar la correcta instalación de los paquetes, se recomienda establecer dependencias entre paquetes.

La regla general son los paquetes que contienen contenido mutable (ui.content) debe depender del código inmutable (ui.apps) que admite la renderización y el uso del contenido mutable.

Una excepción notable a esta regla general es si el paquete de código inmutable (ui.apps o cualquier otro), solamente contiene paquetes OSGi. AEM Si es así, ningún paquete de debe declarar una dependencia en él. El motivo es que los paquetes de código inmutable que solamente AEM contiene paquetes OSGi, no están registrados con los paquetes OSGi Administrador de paquetes. AEM Por lo tanto, cualquier paquete de que dependa de él tiene una dependencia no satisfecha y no se puede instalar.

Los patrones comunes para las dependencias de paquetes de contenido son:

Dependencias del paquete de implementación simple simple-deployment-package-dependencies

El caso simple establece el ui.content paquete de contenido mutable que dependerá del ui.apps paquete de código inmutable.

Dependencias del paquete de implementación compleja complex-deploxment-package-dependencies

Las implementaciones complejas amplían el caso simple y establecen dependencias entre el contenido mutable correspondiente y los paquetes de código inmutable. Según sea necesario, también se pueden establecer dependencias entre paquetes de código inmutable.

Desarrollo e implementación locales local-development-and-deployment

Las estructuras y organización del proyecto descritas en este artículo son las siguientes totalmente compatible AEM desarrollo local de instancias de.

Fragmentos XML de POM pom-xml-snippets

Los siguientes son Maven pom.xml fragmentos de configuración que se pueden añadir a los proyectos de Maven para alinearlos con las recomendaciones anteriores.

Tipos de paquetes xml-package-types

Los paquetes de código y contenido, que se implementan como subpaquetes, deben declarar un tipo de paquete de aplicación o content, dependiendo de lo que contengan.

Tipos de paquetes de contenedores container-package-types

El contenedor all/pom.xml proyecto no tiene declarar un <packageType>.

Tipos de paquetes de código (inmutables) immutable-package-types

Los paquetes de código deben establecer su packageType hasta application.

En el ui.apps/pom.xml, el <packageType>application</packageType> generar directivas de configuración de filevault-package-maven-plugin la declaración del complemento declara su tipo de paquete.

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

Tipos de paquetes de contenido (mutable) mutable-package-types

Los paquetes de contenido deben establecer su packageType hasta content.

En el ui.content/pom.xml, el <packageType>content</packageType> directiva de configuración de compilación de filevault-package-maven-plugin la declaración del complemento declara su tipo de paquete.

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

Marcar paquetes para la implementación de Adobe Cloud Manager cloud-manager-target

En todos los proyectos que generan un paquete, excepto en el proyecto de contenedor (all), agregue <cloudManagerTarget>none</cloudManagerTarget> a la configuración de la declaración del complemento <properties> para garantizar filevault-package-maven-plugin que Adobe Cloud Manager no los implementa. El contenedor (all) paquete debe ser el paquete singular implementado mediante Cloud Manager, que a su vez incorpora todos los paquetes de contenido y código necesarios.

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

Inicio de repo snippet-repo-init

Los scripts de inicio de repo que contienen los scripts de inicio de repo se definen en RepositoryInitializer Configuración de fábrica de OSGi a través de scripts propiedad. Como estos scripts se definen en configuraciones de OSGi, se pueden definir fácilmente mediante el modo de ejecución ../config.<runmode> semántica de carpetas.

Dado que los scripts suelen ser declaraciones multilínea, es más fácil definirlos en la variable .config que el basado en JSON .cfg.json formato.

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

El scripts La propiedad OSGi contiene directivas tal como se definen en Lenguaje de inicialización del repositorio de Apache Sling.

Paquete de estructura de repositorio xml-repository-structure-package

En el ui.apps/pom.xml y cualquier otro pom.xml que declara un paquete de código (<packageType>application</packageType>), agregue la siguiente configuración del paquete de estructura del repositorio al complemento FileVault Maven. Puede cree su propio paquete de estructura de repositorio para el proyecto.

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

Incrustación de subpaquetes en el paquete de contenedor xml-embeddeds

En el all/pom.xml, agregue lo siguiente <embeddeds> directivas al filevault-package-maven-plugin declaración del complemento. Recuerde, no use el <subPackages> configuración. El motivo es que incluye los subpaquetes en /etc/packages en lugar de /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>
...

Definición del filtro del paquete del contenedor xml-container-package-filters

En el all del proyecto filter.xml (all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml), include cualquiera -packages carpetas que contienen subpaquetes para implementar:

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

Si hay varios /apps/*-packages se utilizan en los destinos incrustados, entonces todos deben enumerarse aquí.

Repositorios de Maven de terceros xml-3rd-party-maven-repositories

En el del proyecto del reactor pom.xml, agregue cualquier directiva pública de repositorio de Maven necesaria. El completo <repository> La configuración de debe estar disponible en el proveedor de repositorios de terceros.

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

Dependencias del paquete entre ui.apps de ui.content Paquetes xml-package-dependencies

En el ui.content/pom.xml, agregue lo siguiente <dependencies> directivas al filevault-package-maven-plugin declaración del complemento.

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

Limpiar la carpeta de destino del proyecto de contenedor xml-clean-container-package

En el all/pom.xml, añada el maven-clean-plugin que limpia el directorio de destino antes de una compilación de 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>

Recursos adicionales additional-resources