Familiarize-se com as Uso do Arquétipo de projeto do AEMe o Plug-in FileVault Content Maven à medida que este artigo se baseia nesses aprendizados e conceitos.
Este artigo descreve as alterações necessárias para que os projetos Adobe Experience Manager Maven sejam AEM as a Cloud Service compatíveis, garantindo que eles respeitem a divisão de conteúdo mutável e imutável, que as dependências sejam estabelecidas para criar implantações determinísticas e não conflitantes e que sejam compactadas em uma 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 requer para funcionar, incluindo código, configuração e qualquer conteúdo de linha de base de suporte.
AEM exige a separação de conteúdo e código, o que significa um pacote de conteúdo único cannot implantar em both /apps
e áreas graváveis em tempo de execução (por exemplo, /content
, /conf
, /home
ou nada 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 por AEM Project Maven Archetype 24 ou posterior.
/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á.
Todo o resto no repositório, /content
, /conf
, /var
, /etc
, /oak:index
, /system
, /tmp
, etc. são todas mutável áreas, o que significa que elas podem ser alteradas no tempo de execução.
Como nas versões anteriores do AEM, /libs
não deve ser modificado. Somente AEM código de produto pode ser implantado no /libs
.
Índices do Oak (/oak:index
) são gerenciadas especificamente pelo processo de implantação AEM as a Cloud Service. Isso ocorre porque o Cloud Manager deve aguardar até que qualquer novo índice seja implantado e totalmente reindexado antes de passar 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 parte do Pacote de conteúdo conforme descrito abaixo.
Para obter mais detalhes sobre a indexação AEM as a Cloud Service, consulte o documento Pesquisa e indexação de conteúdo.
Este diagrama fornece uma visão geral da estrutura de projeto recomendada e dos artefatos de implantação de pacote.
A estrutura de implantação do aplicativo recomendada é a seguinte:
O arquivo Jar do pacote OSGi é gerado e diretamente incorporado no projeto inteiro.
O ui.apps
O pacote contém todo o código a ser implantado e somente é implantado em /apps
. Elementos comuns da ui.apps
O pacote inclui, mas não se limita a:
/apps/my-app/components
/apps/my-app/clientlibs
/libs
/apps/cq
, /apps/dam/
, etc./apps/settings
rep:policy
para qualquer caminho em /apps
O mesmo código deve ser implantado em todos os ambientes. Isso é necessário para garantir que um nível de validação de confiança no ambiente de preparo também esteja em produção. Para obter mais informações, consulte a seção em Runmodes.
ui.content
contém todo o conteúdo e configuração. O Pacote de conteúdo contém todas as definições de nó no ui.apps
ou ui.config
pacotes ou, em outras palavras, qualquer item que não esteja em /apps
ou /oak:index
. Elementos comuns da ui.content
O pacote inclui, mas não se limita a:
/conf
/content
, /content/dam
, etc./content/cq:tags
/etc
O all
pacote é um pacote de contêiner que APENAS inclui artefatos implantáveis, o arquivo Jar do pacote OSGI, ui.apps
, ui.config
e ui.content
pacotes como incorporados. O all
o pacote não deve ter qualquer conteúdo ou código próprio, mas delegue toda a implantação no repositório em seus pacotes secundários ou em arquivos Jar do pacote OSGi.
Os pacotes agora são incluídos usando o Maven Configuração incorporada do plug-in FileVault Package Maven, em vez de <subPackages>
configuração.
Para implantações complexas de Experience Manager, pode ser desejável criar vários ui.apps
, ui.config
e ui.content
projetos/pacotes que representam locais ou locatários específicos em AEM. Se isso for feito, verifique se a divisão entre conteúdo mutável e imutável é respeitada, e os pacotes de conteúdo necessários e os arquivos Jar do pacote OSGi são incorporados como subpacotes na variável all
pacote de conteúdo do contêiner.
Por exemplo, uma estrutura complexa de pacote de conteúdo de implantação do pode ser semelhante a:
all
o pacote de conteúdo incorpora os seguintes pacotes para criar um artefato de implantação singular
common.ui.apps
implanta o código exigido por both local A e local Bsite-a.core
Jar do pacote OSGi exigido pelo site Asite-a.ui.apps
implanta o código exigido pelo site Asite-a.ui.config
implanta configurações OSGi necessárias para o Site Asite-a.ui.content
implanta conteúdo e configuração exigidos pelo site Asite-b.core
Jar do pacote OSGi exigido pelo site Bsite-b.ui.apps
implanta o código exigido pelo site Bsite-b.ui.config
implanta configurações OSGi necessárias para o site Bsite-b.ui.content
implanta conteúdo e configuração exigidos pelo site BO ui.config
pacote contém tudo Configurações do OSGi:
/apps/my-app/osgiconfig
/apps/my-app/osgiconfig/config
/apps/my-app/osgiconfig/config.<author|publish>.<dev|stage|prod>
config.<runmode>
conforme descrito acima, e ser usado para definir:
Se outros projetos de AEM, que são eles mesmos compostos de seus próprios pacotes de código e conteúdo, forem usados pela implantação de AEM, seus pacotes de contêiner deverão ser incorporados no all
pacote.
Por exemplo, um projeto de AEM que inclui dois aplicativos de AEM de fornecedor pode ter a seguinte aparência:
all
o pacote de conteúdo incorpora os seguintes pacotes para criar um artefato de implantação singular
core
Jar do pacote OSGi exigido pelo aplicativo AEMui.apps
implanta o código exigido pelo aplicativo AEMui.config
implanta configurações OSGi necessárias para o aplicativo AEMui.content
implanta conteúdo e configuração exigidos pelo aplicativo AEMvendor-x.all
implanta tudo (código e conteúdo) exigido pelo aplicativo X do fornecedorvendor-y.all
implanta tudo (código e conteúdo) exigido pelo aplicativo Y do fornecedorAs embalagens devem ser marcadas com o tipo de pacote declarado. Os tipos de pacote ajudam a esclarecer a finalidade e a implantação de um pacote.
packageType
para container
. Os pacotes de contêiner não devem conter nós regulares. Somente pacotes OSGi, configurações e pacotes secundários são permitidos. Não é permitido usar contêineres em AEM as a Cloud Service instalar ganchos.packageType
para application
.packageType
para content
.Para obter mais informações, consulte Apache Jackrabbit FileVault - Documentação de plug-in do pacote Maven, Tipos de pacotes Apache Jackrabbite o Snippet de configuração do Maven do FileVault abaixo.
Consulte a Trechos de POM XML abaixo para obter um trecho completo.
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 Trechos de POM XML abaixo para obter um trecho completo.
A Init do Repo fornece instruções, ou scripts, que definem estruturas JCR, que vão de estruturas de nós comuns, como árvores de pastas, a usuários, usuários de serviços, grupos e definições de ACL.
Os principais benefícios do Repo Init são ter permissões implícitas para executar todas as ações definidas por seus scripts e serem chamadas no início do ciclo de vida da implantação, garantindo que todas as estruturas JCR necessárias existam pelo código de tempo em que é executado.
Enquanto o Repo Init faz scripts ao vivo no ui.config
projeto como scripts, eles podem e devem ser usados para definir as seguintes estruturas mutáveis:
Os scripts Repo Init são armazenados como scripts
entradas de RepositoryInitializer
As configurações de fábrica do OSGi e, portanto, podem ser implicitamente direcionadas pelo modo de execução, permitindo diferenças entre o autor do AEM e os scripts de inicialização do Repo dos serviços de publicação do AEM, ou até entre ambientes (Dev, Stage e Prod).
As configurações do OSGi da Inicialização do Repo são melhor escritas no .config
Formato de configuração OSGi dado que são compatíveis com várias linhas, o que constitui uma exceção às melhores práticas de utilização .cfg.json
para definir configurações OSGi.
Observe que, ao definir Usuários e Grupos, somente grupos são considerados parte do aplicativo, e parte integrante de sua função deve ser definida aqui. Usuários e grupos da organização ainda devem ser definidos no tempo de execução em AEM; por exemplo, se um fluxo de trabalho personalizado atribuir trabalho a um Grupo nomeado, esse Grupo deverá ser definido em por meio da Inicialização do Repo no aplicativo AEM, no entanto, se o Agrupamento for meramente organizacional, como "Equipe da Wendy" e "Equipe do Sean", eles serão melhor definidos e gerenciados no tempo de execução em AEM.
Scripts Repo Init must ser definido em linha scripts
e o references
configuração não funcionará.
O vocabulário completo dos scripts do Repo Init está disponível no Documentação de inicialização do Apache Sling Repo.
Consulte a Trechos da Inicialização do Repo abaixo para obter um trecho completo.
Pacotes de código exigem a configuração do plug-in FileVault Maven para fazer referência a um <repositoryStructurePackage>
que aplica corretamente as 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 o 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 do repositório.
Observe que os pacotes de conteúdo (<packageType>content</packageType>
) não requerem este pacote de estrutura de repositório.
Consulte a Trechos de POM XML abaixo para obter um trecho completo.
O conteúdo ou os pacotes de código são colocados em uma pasta "carro lateral" especial e podem ser destinados à instalação AEM autor, AEM publicação ou ambos, usando o plug-in FileVault Maven <embeddeds>
configuração. Observe que a variável <subPackages>
não deve ser usada.
Os casos de uso comuns incluem:
Para direcionar AEM autor, AEM publicação ou ambos, o pacote é incorporado na all
pacote de contêiner em um local de pasta especial, no seguinte formato:
/apps/<app-name>-packages/(content|application|container)/install(.author|.publish)?
Analisando esta estrutura de pastas:
A pasta de primeiro nível deve ser /apps
.
A pasta de segundo nível representa o aplicativo com -packages
corrigido no nome da pasta. Geralmente, há apenas uma única pasta de segundo nível em que todos os sub-pacotes 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
, content
ou container
application
pacotes de código de retenções de pastacontent
pasta contém pacotes de conteúdocontainer
a pasta contém qualquer pacotes de aplicativos extras que pode ser incluído pelo aplicativo AEM.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 AEMinstall.author
para instalar somente no autor do AEMinstall.publish
para only instalar em AEM publicar Observe que somente install.author
e install.publish
são alvos compatíveis. Outros modos de execução não são compatíveis.Por exemplo, uma implantação que contém AEM criar e publicar pacotes específicos pode ser semelhante ao seguinte:
all
O pacote de contêiner incorpora os seguintes pacotes para criar um artefato de implantação singular
ui.apps
incorporado no /apps/my-app-packages/application/install
implanta o código para AEM autor e AEM publicaçãoui.apps.author
incorporado no /apps/my-app-packages/application/install.author
implanta o código somente AEM autorui.content
incorporado no /apps/my-app-packages/content/install
implanta conteúdo e configuração em autor AEM e publicação AEMui.content.publish
incorporado no /apps/my-app-packages/content/install.publish
implanta conteúdo e configuração somente AEM publicaçãoConsulte a Trechos de POM XML abaixo para obter um trecho completo.
Devido à incorporação dos subpacotes de código e conteúdo no pacote do contêiner, os caminhos de destino incorporados devem ser adicionados ao projeto do contêiner filter.xml
para garantir que os pacotes incorporados sejam incluídos no pacote do contêiner quando criados.
Basta adicionar o <filter root="/apps/<my-app>-packages"/>
entradas para qualquer pasta de segundo nível que contenha pacotes secundários a serem implantados.
Consulte a Trechos de POM XML abaixo para obter um trecho completo.
Todos os pacotes devem estar disponíveis através do Artefato de Adobe ou 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.
Aplicativos/conectores de terceiros devem ser incorporados usando seus all
como um contêiner no contêiner do seu projeto (all
).
A adição de dependências de 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 descrito acima.
Consulte a Trechos de POM XML abaixo para obter um trecho completo.
ui.apps
from ui.content
PacotesPara garantir a instalação correta das embalagens, recomenda-se estabelecer as dependências entre pacotes.
A regra geral é pacotes contendo conteúdo mutável (ui.content
) deve 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 para essa regra geral é se o pacote de código imutável (ui.apps
ou qualquer outro), only contém pacotes OSGi. Em caso afirmativo, nenhum pacote AEM deve declarar uma dependência em relação a ele. Isso ocorre porque pacotes de código imutáveis only contendo pacotes OSGi não estão registrados com AEM Gerenciador de pacotes, e, portanto, qualquer pacote AEM dependendo dele terá uma dependência insatisfeita e não será instalado.
Consulte a Trechos de POM XML abaixo para obter um trecho completo.
Os padrões comuns para dependências de pacotes de conteúdo são:
As letras maiúsculas e minúsculas simples definem a variável ui.content
o pacote de conteúdo mutável para depender do ui.apps
pacote de código imutável.
all
não tem dependências
ui.apps
não tem dependênciasui.content
depende de ui.apps
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 tem dependências
common.ui.apps.common
não tem dependênciassite-a.ui.apps
depende de common.ui.apps
site-a.ui.content
depende de site-a.ui.apps
site-b.ui.apps
depende de common.ui.apps
site-b.ui.content
depende de site-b.ui.apps
As estruturas e a organização do projeto descritas neste artigo são totalmente compatível instâncias de desenvolvimento local AEM.
As seguintes são Maven pom.xml
trechos de configuração que podem ser adicionados a projetos Maven para alinhar-se às recomendações acima.
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.
O contêiner all/pom.xml
projeto não declare a <packageType>
.
Os pacotes de código devem definir seus packageType
para application
.
No ui.apps/pom.xml
, o <packageType>application</packageType>
diretivas de configuração de build do filevault-package-maven-plugin
declaração de plug-in declara o 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>
...
Os pacotes de conteúdo devem definir seus packageType
para content
.
No ui.content/pom.xml
, o <packageType>content</packageType>
diretiva de configuração de build do filevault-package-maven-plugin
declaração de plug-in declara o 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>
...
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. O contêiner (all
) deve ser o único pacote implantado pelo Cloud Manager, que, por sua vez, incorpora todos os pacotes de código e conteúdo necessários.
...
<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>
...
Os scripts Repo Init que contêm os scripts Repo Init são definidos na variável RepositoryInitializer
Configuração de fábrica OSGi por meio do scripts
propriedade. Observe que, como esses scripts são definidos nas configurações OSGi, eles podem ser facilmente escopo por modo de execução usando o modo normal ../config.<runmode>
semântica de pasta.
Observe que, como os scripts geralmente são declarações de várias linhas, é mais fácil defini-los no .config
, em vez de baseado em 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
"]
O scripts
A propriedade OSGi contém diretivas, conforme definido pelo Idioma do Repo Init do Apache Sling.
No ui.apps/pom.xml
e quaisquer outros pom.xml
que declara uma embalagem de código (<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 o 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>
...
No all/pom.xml
, adicione o seguinte <embeddeds>
as diretivas filevault-package-maven-plugin
declaração de plug-in. Lembre-se, não use o <subPackages>
, pois incluirá os subpacotes em /etc/packages
em vez 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>
...
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
são usados nos targets incorporados, então todos devem ser enumerados aqui.
A adição de mais repositórios Maven pode estender os tempos de build maven, pois 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úblicas de terceiros necessárias. O <repository>
A configuração 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>
ui.apps
from ui.content
PacotesNo ui.content/pom.xml
, adicione o seguinte <dependencies>
as diretivas filevault-package-maven-plugin
declaração de 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>
...
No all/pom.xml
adicione o maven-clean-plugin
que limpará o diretório de destino antes de uma compilação 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>