Show Menu
TÓPICOS×

Estrutura de projetos do AEM

Familiarize-se com o uso básico do AEM Project Archetype e com o plug-in vlt-mavenplugin.html FileVault Content Maven, já que este artigo se baseia nesses aprendizados e conceitos.
Este artigo descreve as mudanças necessárias para que os projetos Adobe Experience Manager Maven sejam AEM compatíveis, garantindo que respeitem a divisão de conteúdos mutáveis e imutáveis. que sejam estabelecidas as dependências necessárias para criar implantações determinísticas e não conflitantes; E que eles são empacotados numa estrutura implantável.
AEM implantações de aplicativos devem ser compostas por um único pacote AEM. Este pacote deve, por sua vez, conter subpacotes que contêm tudo o que o aplicativo exige para funcionar, incluindo código, configuração e qualquer conteúdo básico de suporte.
O AEM requer uma separação de conteúdo e código , ou seja, um único pacote de conteúdo não pode ser implantado em ambos /apps as áreas graváveis em tempo de execução (por exemplo, /content , /conf , /home ou qualquer outra que não /apps ) do repositório. Em vez disso, o aplicativo deve separar código e conteúdo em pacotes separados para implantação no AEM.
A estrutura do pacote descrita neste documento é compatível com ambas as implantações de desenvolvimento locais e implantações do serviço da AEM Cloud.
As configurações descritas neste documento são fornecidas pelo AEM Project Maven Archetype 21 ou posterior .

Áreas mutáveis vs. imutáveis do repositório

/apps e /libs são consideradas áreas imutáveis do AEM, pois não podem ser alteradas (criar, atualizar, excluir) após o AEM ser iniciado (isto é, no tempo de execução). Qualquer tentativa de alterar uma área imutável no tempo de execução falhará.
Everything else in the repository, /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.
Como nas versões anteriores do AEM, não /libs deve ser modificado. Somente AEM código de produto pode ser implantado em /libs .

Índices de Oak

Os índices Oak ( /oak:index ) são gerenciados especificamente pelo processo de implantação do AEM Cloud Service. Isso ocorre porque o Gerenciador de nuvem deve aguardar até que qualquer novo índice seja implantado e totalmente indexado novamente antes de alternar para a nova imagem de código.
Por isso, embora os índices Oak sejam mutáveis em tempo de execução, eles devem ser implantados como código para que possam ser instalados antes que qualquer pacote mutável seja instalado. Portanto, /oak:index as configurações fazem parte do Pacote de código e não fazem parte do Pacote de conteúdo, conforme descrito abaixo.
Para obter mais detalhes sobre a indexação em AEM como Cloud Service, consulte a Pesquisa e indexação de conteúdo do documento.

Tipos de encapsulamento

As embalagens devem ser marcadas com o tipo de embalagem declarado.
  • Os pacotes de container não devem ter um packageType conjunto.
  • Os pacotes de código (imutáveis) devem definir seus packageType como application .
  • Os pacotes de conteúdo (mutável) devem definir packageType como content .
Para obter mais informações, consulte Apache Jackrabbit FileVault - documentação do plug-in Package Maven e o trecho de configuração FileVault Maven abaixo.
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Pacotes de marcação para implantação pelo gerenciador da Adobe Cloud

Por padrão, o Adobe Cloud Manager coleta todos os pacotes produzidos pela compilação Maven. No entanto, como o pacote do contêiner ( all ) é o artefato de implantação singular que contém todos os pacotes de código e conteúdo, devemos garantir que somente o pacote do contêiner ( all ) seja implantado. Para garantir isso, outros pacotes gerados pela compilação Maven devem ser marcados com a configuração do Plug-in FileVault Content Package Maven do <properties><cloudManagerTarget>none</cloudManageTarget></properties> .
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Inicialização do Repo

A Inicialização do Repo fornece instruções, ou scripts, que definem estruturas JCR, desde estruturas de nós comuns, como árvores de pastas, até usuários, usuários de serviços, grupos e definição de ACL.
Os principais benefícios do Repo Init são ter permissões implícitas para executar todas as ações definidas pelos scripts e serem chamadas no início do ciclo de vida da implantação, garantindo que todas as estruturas JCR necessárias existam até que o código seja executado.
Embora o Repo Init faça scripts em tempo real no ui.apps projeto como scripts, eles podem e devem ser usados para definir as seguintes estruturas mutáveis:
  • Estruturas de conteúdo da linha de base
    • Examples: /content/my-app , /content/dam/my-app , /conf/my-app/settings
  • Usuários do serviço
  • Usuários
  • Grupos
  • ACLs
Os scripts de Inicialização de Repo são armazenados como entradas de configurações de fábrica do scripts RepositoryInitializer OSGi e, portanto, podem ser implicitamente direcionados pelo modo de execução, permitindo diferenças entre os scripts de Inicialização de Repo do autor do AEM e dos Serviços de publicação do AEM, ou mesmo entre Envs (Dev, Stage e Prod).
Observe que, ao definir Usuários e Grupos, somente grupos são considerados parte do aplicativo e integrantes de sua função devem ser definidos aqui. Os utilizadores e grupos da organização devem ainda ser definidos em tempo de execução no AEM; por exemplo, se um fluxo de trabalho personalizado atribuir trabalho a um Grupo nomeado, esse Grupo deverá ser definido por meio da Inicialização de Repo no aplicativo AEM, no entanto, se o Agrupamento for meramente organizacional, como "Equipe de Wendy" e "Equipe de Sean", eles serão melhor definidos e gerenciados no tempo de execução em AEM.
Os scripts de inicialização de acordo com o repo devem ser definidos no campo em linha scripts references e a configuração não funcionará.
O vocabulário completo para scripts do Repo Init está disponível na documentação do Apache Sling Repo Init.
Consulte a seção Repo Init Snippets abaixo para obter um trecho completo.

Pacote de estrutura do repositório

Os Pacotes de código exigem a configuração do plug-in FileVault Maven para fazer referência a uma configuração <repositoryStructurePackage> que imponha a correção das dependências estruturais (para garantir que um pacote de código não seja instalado sobre outro). Você pode criar seu próprio pacote de estrutura de repositório para seu projeto .
Isso só é necessário em Pacotes de código, ou seja, qualquer pacote marcado com <packageType>application</packageType> .
Para saber como criar um pacote de estrutura de repositório para seu aplicativo, consulte Desenvolver um pacote de estrutura de repositório.
Observe que os pacotes de conteúdo ( <packageType>content</packageType> ) não exigem este Pacote de estrutura de repositório.
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Incorporação de subpacotes no pacote de Container

Os pacotes de conteúdo ou código são colocados em uma pasta especial "carro lateral" e podem ser direcionados para instalação AEM autor, AEM publicação ou ambos, usando a configuração do plug-in FileVault Maven <embeddeds> . Observe que a <subPackages> configuração não deve ser usada.
Os casos de uso frequentes incluem:
  • ACLs/permissões que diferem entre AEM usuários do autor e AEM usuários de publicação
  • Configurações usadas para suportar atividades somente AEM autor
  • Código como integrações com sistemas de back-office, necessário apenas para execução AEM autor
Para criar AEM público alvo, AEM publicar ou ambos, o pacote é incorporado no pacote do all container em um local de pasta especial, no seguinte formato:
/apps/<app-name>-packages/(content|application)/install(.author|.publish)?
Detalhando a estrutura desta pasta:
  • A pasta de primeiro nível deve ser /apps .
  • A pasta de segundo nível representa o aplicativo com -packages post-fixed no nome da pasta. Muitas vezes, há apenas uma única pasta de segundo nível na qual todos os subpacotes são incorporados, no entanto, qualquer número de pastas de segundo nível pode ser criado para melhor representar a estrutura lógica do aplicativo:
    • /apps/my-app-packages
    • /apps/my-other-app-packages
    • /apps/vendor-packages
    Por convenção, as pastas incorporadas do pacote secundário são nomeadas com o sufixo -packages . Isso garante que o código de implantação e os pacotes de conteúdo não sejam implantados nas pastas de destino de qualquer pacote secundário /apps/<app-name>/... que resulte em comportamento de instalação destrutivo e cíclico.
  • A pasta de terceiro nível deve ser application ou content
    • A application pasta contém pacotes de códigos
    • A content pasta contém pacotes de conteúdo. Esse nome de pasta deve corresponder aos tipos de pacote dos pacotes que contém.
  • A pasta de 4º nível contém os pacotes secundários e deve ser uma das seguintes:
    • install para instalar no autor do AEM e na publicação do AEM
    • install.author para instalar somente no autor do AEM
    • install.publish para instalar somente AEM publicarObserve que somente install.author e install.publish são públicos alvos suportados. Outros modos de execução não são compatíveis.
Por exemplo, uma implantação que contém AEM pacotes específicos de autor e publicação pode ser semelhante ao seguinte:
  • all O pacote de container incorpora os seguintes pacotes para criar um artefato de implantação singular
    • ui.apps incorporado em /apps/my-app-packages/application/install implanta código para autor AEM e publicação AEM
    • ui.apps.author incorporado em /apps/my-app-packages/application/install.author implanta código somente para AEM autor
    • ui.content incorporado na /apps/my-app-packages/content/install implanta conteúdo e configuração para AEM autor e publicação AEM
    • ui.content.publish incorporado em /apps/my-app-packages/content/install.publish implanta conteúdo e configuração somente para AEM publicação
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Definição de Filtro do Pacote de container

Devido à incorporação dos subpacotes de código e conteúdo no pacote de container, os caminhos de públicos alvos incorporados devem ser adicionados ao projeto do container filter.xml para garantir que os pacotes incorporados sejam incluídos no pacote do container quando criados.
Basta adicionar as <filter root="/apps/<my-app>-packages"/> entradas para qualquer pasta de segundo nível que contenha subpacotes a serem implantados.
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Como incorporar pacotes de terceiros

Todos os pacotes devem estar disponíveis por meio do repositório público de artefatos Maven ou de um repositório de artefatos Maven de terceiros acessível e referenciável.
Se os pacotes de terceiros estiverem no repositório público de artefatos Maven da Adobe , nenhuma configuração adicional será necessária para o Adobe Cloud Manager resolver os artefatos.
Se os pacotes de terceiros estiverem em um repositório de artefatos Maven de terceiros público , esse repositório deverá ser registrado no pom.xml do projeto e incorporado de acordo com o método descrito acima . Se o aplicativo/conector de terceiros exigir pacotes de código e conteúdo, cada um deles deve ser incorporado aos locais corretos no pacote do contêiner ( all ).
A adição de dependências Maven segue as práticas padrão de Maven e a incorporação de artefatos de terceiros (pacotes de código e conteúdo) são descritas acima .
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.

Dependências do pacote entre ui.apps os ui.content pacotes

A fim de garantir a instalação correta das embalagens, recomenda-se estabelecer as dependências entre embalagens.
A regra geral é que os pacotes que contêm conteúdo mutável ( ui.content ) devem depender do código imutável ( ui.apps ) que suporta a renderização e o uso do conteúdo mutável.
Uma exceção notável a essa regra geral é se o pacote de código imutável ( ui.apps ou qualquer outro) contiver apenas pacotes OSGi. Em caso afirmativo, nenhum pacote AEM deve declarar uma dependência do mesmo. Isso ocorre porque os pacotes de código imutáveis ____ que contêm pacotes OSGi não estão registrados no Gerenciador de pacotes AEM e, portanto, qualquer pacote AEM que dependa dele terá uma dependência insatisfatória e não será instalado.
Consulte a seção Trechos XML POM abaixo para obter um trecho completo.
Os padrões comuns para dependências de pacotes de conteúdo são:

Dependências do pacote de implantação simples

O caso simples define o pacote de conteúdo ui.content mutável para depender do pacote de código ui.apps imutável.
  • all não possui dependências
    • ui.apps não possui dependências
    • ui.content depende de ui.apps

Dependências complexas do pacote de implantação

Implantações complexas se expandem no caso simples e definem dependências entre o conteúdo mutável correspondente e os pacotes de código imutáveis. Conforme necessário, as dependências também podem ser estabelecidas entre pacotes de código imutáveis.
  • all não possui dependências
    • ui.apps.common não possui dependências
    • ui.apps.site-a depende de ui.apps.common
    • ui.content.site-a depende de ui.apps.site-a
    • ui.apps.site-b depende de ui.apps.common
    • ui.content.site-b depende de ui.apps.site-b

Desenvolvimento local e implantação

As estruturas e a organização do projeto descritas neste artigo são instâncias de desenvolvimento local totalmente compatíveis AEM.

Trechos XML POM

A seguir estão trechos pom.xml de configuração Maven que podem ser adicionados aos projetos Maven para alinhar às recomendações acima.

Tipos de encapsulamento

Os pacotes de código e conteúdo, que são implantados como pacotes secundários, devem declarar um tipo de pacote de aplicativo ou conteúdo , dependendo do que eles contêm.

Tipos de encapsulamento de container

O projeto container all/pom.xml não declara um <packageType> .

Tipos de encapsulamento de código (imutável)

Os pacotes de código devem definir packageType como application .
Na ui.apps/pom.xml , as diretivas de configuração de <packageType>application</packageType> compilação da declaração de filevault-package-maven-plugin plug-in declaram seu tipo de pacote.
...
<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 encapsulamento de conteúdo (variável)

Os pacotes de conteúdo devem definir packageType como content .
Na ui.content/pom.xml , a diretiva de configuração de <packageType>content</packageType> compilação da declaração de filevault-package-maven-plugin plug-in declara seu tipo de pacote.
...
<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>
    ...

Marking Packages for Adobe Cloud Manager Deployment

Em todos os projetos que geram um pacote, exceto do projeto do contêiner ( all ), adicione <cloudManagerTarget>none</cloudManagerTarget> à configuração <properties> da declaração do plug-in filevault-package-maven-plugin para garantir que eles não sejam implantados pelo Adobe Cloud Manager. The container ( all ) package should be the singular package deployed via Cloud Manager, which in turn embeds all required code and content packages.
...
<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>
    ...

Inicialização do Repo

Os scripts de Inicialização do Repo que contêm os scripts de Inicialização do Repo são definidos na configuração de fábrica RepositoryInitializer OSGi por meio da scripts propriedade. Observe que, como esses scripts são definidos em configurações OSGi, eles podem ser facilmente escopo por modo de execução usando a semântica de ../config.<runmode> pasta comum.
Observe que, como os scripts normalmente são declarações de várias linhas, é mais fácil defini-los no .config arquivo do que no formato de bases XML sling:OsgiConfig .
/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
"]

A propriedade scripts OSGi contém diretivas, conforme definido pela linguagem de Inicialização do Apache Sling.

Pacote de estrutura do repositório

No ui.apps/pom.xml e em qualquer outra pom.xml que declare um pacote de códigos ( <packageType>application</packageType> ), adicione a seguinte configuração de pacote de estrutura de repositório ao plug-in FileVault Maven. Você pode criar seu próprio pacote de estrutura de repositório para seu projeto .
...
<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>
    ...

Incorporação de subpacotes no pacote de Container

Na all/pom.xml , adicione as seguintes <embeddeds> diretivas à declaração de filevault-package-maven-plugin plug-in. Lembre-se de não usar a <subPackages> configuração, pois isso incluirá os subpacotes em /etc/packages vez de /apps/my-app-packages/<application|content>/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 -->

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

          <!-- 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 such as AEM WCM Core Components -->
          <embedded>
              <groupId>com.adobe.cq</groupId>
              <!-- Not to be confused; WCM Core Components' Code package's artifact is named `.content` -->
              <artifactId>core.wcm.components.content</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/application/install</target>
          </embedded>

          <embedded>
              <groupId>com.adobe.cq</groupId>
              <!-- Not to be confused; WCM Core Components' Content package's artifact is named `.conf` -->
              <artifactId>core.wcm.components.conf</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/content/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Definição de Filtro do Pacote de container

No filter.xml ( all/src/main/content/jcr_root/META-INF/vault/definition/filter.xml ) do projeto all , inclua as pastas -packages que contêm pacotes secundários a serem implantados:
<filter root="/apps/my-app-packages"/>

Se vários /apps/*-packages forem usados nos públicos alvos incorporados, todos devem ser enumerados aqui.

Repositórios Maven de terceiros

A adição de mais repositórios Maven pode estender os tempos de criação de maven, já que repositórios Maven adicionais serão verificados quanto às dependências.
No projeto do reator pom.xml , adicione quaisquer diretivas de repositório Maven público de terceiros. A <repository> configuração completa deve estar disponível no provedor de repositório de terceiros.
<repositories>
  ...
  <repository>
      <id>3rd-party-repository</id>
      <name>Public 3rd 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>

Dependências do pacote entre ui.apps os ui.content pacotes

Na ui.content/pom.xml , adicione as seguintes <dependencies> diretivas à declaração de filevault-package-maven-plugin plug-in.
...
<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>
...

Limpando a pasta de Públicos alvos do projeto do Container

Na página all/pom.xml , adicione o plug- maven-clean-plugin in que limpará o diretório do público alvo antes das compilações do 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>