Conteúdo


Cinco coisas que você não sabia sobre...

Plug-ins do Apache Maven

Dicas para dominar os plug-ins modernos do Maven

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Cinco coisas que você não sabia sobre...

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Cinco coisas que você não sabia sobre...

Fique ligado em conteúdos adicionais dessa série.

Você conhece o Maven?

O Maven é o gerenciamento de dependência e a ferramenta de construção líder para desenvolvedores Java™ e com bom motivo! Ele padroniza o processo de construção de software articulando a constituição de um projeto, implementando-o como um aplicativo e compartilhando-o com outros projetos.

O Maven emprega um conjunto de plug-in robusto que fornece todas as suas funcionalidades. No Maven, os plug-ins têm objetivos, que, nos bastidores, são apenas métodos Java. Os objetivos executam as tarefas de construção como compilar o projeto, empacotá-lo e implementá-lo em um servidor local ou remoto. Essas atividades são perfeitamente mapeadas para desenvolver fases de ciclo de vida.

O Maven é fornecido com seus plug-ins de construção empacotados e prontos para usar, e os padrões são pré-configurados. A convenção sobre a configuração assegura que a configuração seja escalada de acordo com a complexidade de determinada tarefa. A maioria das tarefas de construção requerem uma configuração bem mínima.

Também é possível customizar o comportamento dos plug-ins do Maven. É fácil substituir os padrões do plug-in e definir novos valores usando a <configuração> do Maven. Sem dúvida, os valores padrão mais substituíveis são os valores de <target> e <source> do plug-in compilador.

Precisa de provas? Quantas vezes você incluiu o XML na Listagem 1 em seu POM para configurar a versão correta da JVM?

Lista 1. A configuração da versão Java no plug-in do compilador
<plugin>
   <groupId>org.apache.maven.plug-ins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>3.6.1</version>
   <configuration>
       <source>1.8</source>
       <target>1.8</target>
   </configuration>
</plugin>

Executando o ciclo de vida do Maven

Cada objetivo do plug-in é mapeado para uma fase do ciclo de vida do Maven. Emitir o comando mvn compile instrui o utilitário mvn a chamar todos os objetivos vinculados à compile. O objetivo de compile do plug-in compiler é vinculado a essa fase do ciclo de vida.

O relacionamento de fase para objetivo é um para muitos. Diversos objetivos de plug-in podem ser vinculados à mesma fase para formar uma coleção de tarefas relacionadas. As fases também são hierárquicas, significando que a execução de uma fase causa a execução de todas as suas fases precedentes.

Nesse caso, a emissão do comando mvn compile inicia a fase validate (que é a primeira fase do ciclo de vida de construção padrão do Maven), chamando todos os objetivos vinculados a essa fase.

Os websites do Maven e do Google Code mantêm uma lista dos plug-ins do Maven. Esses plug-ins fornecem uma variedade de funcionalidades úteis que economizam tempo e podem ser incorporadas no processo de construção. Vou apresentar alguns dos mais úteis que já encontrei e mostrar como aproveitá-los ao máximo.

1. Assinar digitalmente um JAR ou WAR

Clique no botão abaixo para fazer o download do código deste exemplo. Ele contém um aplicativo simples e um arquivo POM com um plug-in Jarsigner configurado.

Assinar digitalmente um JAR ou WAR é uma tarefa importante, principalmente se você desejar distribuir o aplicativo. Felizmente, a plataforma Java fornece um utilitário de assinatura de archive chamado jarsigner. É uma ferramenta de linha de comando que assina um archive quando você insere o local do archive, juntamente vários parâmetros, como o keystore que contém as chaves criptográficas.

É possível localizar jarsigner no diretório <%JAVA_HOME%>/bin da instalação do JDK. A Listagem 2 mostra como assinar um JAR usando este utilitário.

Lista 2. Assinar um archive usando o utilitário jarsigner
jarsigner
    -keystore /path/to/keystore.jks
    -storepass <password>
    -keypass <key password>
    YourArchive.jar
    alias

Simples de instalar, o jarsigner é um ferramenta de linha de comando fácil de usar. Mas não seria bom automatizar o processo de assinatura e fazer com que o archive fosse assinado durante a fase pacote do ciclo de construção? Bem, isso pode ser feito graças ao plug-in Jarsigner do Maven, que agrupa o utilitário jarsigner. Basta vincular o objetivo sign do plug-in à fase pacote da construção.

Para iniciar, é necessário um keystore. Se você ainda não tiver, será possível criá-lo com o utilitário keytool da plataforma Java, localizado no diretório <%JAVA_HOME%>/bin da instalação do JDK.

Criando um keystore

Para criar um keystore, navegue para o local onde deseja que ele esteja e execute o comando na Listagem 3. Assegure-se de substituir KeyAlias por um valor apropriado como o nome do domínio. O nó documentação oficial do Oracle detalha ainda mais as opções de configuração que a ferramenta aceita.

Lista 3. Criando um keystore para o utilitário jarsigner
keytool -genkey -alias <KeyAlias> -keyalg RSA -keystore keystore.jks -keysize 2048

O processo de criação de um keystore requer que você responda a uma série de perguntas sobre você e sobre sua organização e ainda forneça uma senha segura. Essa senha será necessária para configurar o plug-in Jarsigner do Maven, o que você fará em seguida.

Inclua o Jarsigner no processo de construção

Agora, você incluirá o plug-in Jarsigner do Mavem no ciclo de vida de construção e, em seguida, o configurará para assinar digitalmente um JAR produzido durante a fase pacote. Faz sentido conectar a essa fase porque o JAR já foi construído e armazenado no diretório de saída padrão do projeto, que geralmente é o target . Na seção <plug-ins> do arquivo POM, inclua o código mostrado na Listagem 4.

Lista 4. Incluindo o plug-in Jarsigner
<plugin>
   <groupId>org.apache.maven.plug-ins</groupId>
   <artifactId>maven-jarsigner-plugin</artifactId>
   <version>1.4</version>
</plugin>

Você deseja que o JAR seja assinado depois de ser construído, portanto, é necessário conectar o processo de assinatura (que está agrupado no objetivo sign) à fase do ciclo de vida do pacote. Para fazer isso, inclua o código na Listagem 5 ao plug-in.

Lista 5. Conectando o objetivo de assinatura à fase de pacote
   <executions>
       <execution>
           <id>sign</id>
           <phase>package</phase>
           <goals>
               <goal>sign</goal>
           </goals>
       </execution>
   </executions>

O objetivo sign precisa de alguns detalhes de configuração para poder assinar o JAR digitalmente. Portanto, entre os elementos <configuration>, deve-se incluir o local do keystore, o alias das credenciais que deseja usar, a senha de armazenamento e a senha das credenciais, como é mostrado na Listagem 6.

Lista 6. Especificando a credencial de segurança
<configuration>
   <keystore>/location/of/keystore.jks</keystore>
   <alias>KeyAlias</alias>
   <storepass>password</storepass>
   <keypass>password</keypass>
</configuration>

Essa é a configuração mínima para fazer com que o recurso de assinatura do JAR funcione. Observe que o plug-in fornece uma bela variedade de opções de configuração adicionais para escolher.

A etapa final é criar o JAR e verificar se ele foi assinado corretamente. A partir da linha de comando, execute o objetivo pacote da seguinte forma: mvn clean package. Na saída do console, você verá o JAR sendo construído e, em seguida, sendo assinado. A Figura 1 mostra como seria isso.

Figura 1. Saída mostrando o archive assinado
Output showing archive signed
Output showing archive signed

O JAR será construído no diretório de saída target, e é nesse local que o plug-in Jarsigner espera encontrá-lo. O plug-in assinará o JAR com as credenciais fornecidas e, em seguida, incluirá dois arquivos adicionais ao diretório META-INF: um arquivo de assinaturas com uma extensão .SF e um bloco de assinatura com uma extensão .RSA.

Agora você tem um JAR assinado digitalmente pronto para distribuição.

Verifique a assinatura digital

Antes de distribuir o JAR, vamos verificar se ele foi assinado de forma adequada. É possível fazer isso com o objetivo verify do Jarsigner do Maven, ou por meio da linha de comandos usando o jarsigner . Na Listagem 7, eu usei a ferramenta de linha de comando e passei o archive que deseja verificar.

Lista 7. Usando o utilitário jarsigner para verificar um JAR assinado
jarsigner -verify target/YourJavaArchive.jar

Caso seja bem-sucedido, você receberá a mensagem: jar verified.

Assinando arquivos WAR

A assinatura de JAR não é a única carta que o Jarsigner tem na manga. O plug-in pode assinar qualquer arquivo Java archive, incluindo arquivos WAR. Para ver como isso funciona, altere o tipo de pacote do POM de JAR para WAR, inclua o plug-in WAR do Maven (como é mostrado na Listagem 8) e execute o comando: mvn clean package.

Lista 8. Incluindo o plug-in WAR do Maven
<plugin>
   <groupId>org.apache.maven.plug-ins</groupId>
   <artifactId>maven-war-plugin</artifactId>
   <version>3.1.0</version>
</plugin>

Verifique o diretório target e você verá que o arquivo WAR já foi assinado.

Assinando vários archives

Se você tiver mais de um archive para assinar, o Jarsigner também poderá manipular essa situação. O código na Listagem 9 especifica o local dos JARs a serem assinados como target/all e todos os JARs no diretório serão assinados.

Lista 9. Especificando um diretório de archive
<archiveDirectory>target/all</archiveDirectory>

Se você precisar de um controle com uma granularidade mais baixa sobre os archives a serem assinados, será possível usar coringas para incluir e excluir arquivos explicitamente, como é mostrado na Listagem 10.

Lista 10. Incluindo e excluindo archives selecionados
<includes>
   <include>*1.0.jar</include>
</includes>
<excludes>
   <exclude>*SNAPSHOT.jar</exclude>
</excludes>

2. Implementar um aplicativo da web protegido com o Maven Cargo

Clique no botão abaixo para fazer o download do código deste exemplo. Ele contém um aplicativo da web simples e um arquivo POM com um plug-in Cargo configurado

O Plug-in Cargo da Codehaus é um wrapper para a API Cargo. A API é projetada para configurar, iniciar, parar e implementar aplicativos em um intervalo contêineres com suporte, além de analisar, criar e mesclar módulos Java EE.

Um recurso especificamente interessante é a capacidade do Cargo de especificar as propriedades do servidor de uma maneira agnóstica em relação a contêiner. Essas propriedades incluem portas, credenciais de segurança remotas, argumentos da JVM e — o mais relevante para o nosso interesse — os detalhes de login para usuários do aplicativo que você deseja implementar. O plug-in oferece suporte para 14 dos servidores mais populares, diretamente para a edição mais recente de cada um.

O plug-in Cargo funciona melhor conectado à fase pacote do ciclo de vida do Maven. Ele também pode ser executado de forma independente referenciando o objetivo run diretamente: mvn cargo:run. A execução independente assume que o projeto já foi empacotado e está pronto para a implementação.

Vamos começar conectando o objetivo run do Cargo à fase package, como é mostrado na Listagem 11.

Lista 11. Conectando o objetivo de execução do Cargo à fase de pacote
<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven2-plugin</artifactId>
   <version>1.6.4</version>
   <executions>
       <execution>
           <phase>package</phase>
           <goals>
               <goal>run</goal>
           </goals>
       </execution>
   </executions>
</plugin>

Com a integração do Maven concluída, agora é necessário configurar o contêiner no qual deseja que o Cargo implemente o aplicativo. O Cargo oferece suporte a uma variedade de cenários de contêiner, incluindo a implementação em um servidor local ou remoto que já esteja em execução (que inclui iniciar o servidor, caso seja necessário). Como alternativa, o Cargo pode ser configurado para fazer download, instalar, implementar e iniciar um dos 14 servidores com suporte.

Para este exemplo, vou usar o O IBM® O WebSphere® Liberdade que já transferi por download para um diretório chamado servers.

O nó configuração de contêiner espera pelo menos o ID do contêiner e o local inicial do servidor instalado. A Listagem 12 mostra a configuração de um servidor Liberty localizado em meus servers/wlp.

Lista 12. Configuração de contêiner
<configuration>
   <container>
       <containerId>liberty</containerId>
       <home>\path\to\servers\wlp</home>
   </container>
</configuration>

Faça download do ZIP do contêiner

Outra opção é especificar a URL do ZIP do Liberty no website da IBM e, nesse caso, o plug-in Cargo fará o download e instalará o servidor. A Listagem 13 mostra como seria isso.

Lista 13. Instalando o contêiner a partir da web
<container>
   <containerId>liberty</containerId>
   <zipUrlInstaller>
       <url>
              https://public.dhe.ibm.com/ibmdl/export/pub/
              software/websphere/wasdev/downloads/wlp/17.0.0.2/
              wlp-webProfile7-17.0.0.2.zip
       </url>
       <downloadDir>/path/to/downloadDir</downloadDir>
       <extractDir>/path/to/extractDir</extractDir>
   </zipUrlInstaller>
</container>

Na primeira vez que você executar o objetivo run, o arquivo ZIP será transferido por download e extraído. Nas próximas execuções o Maven detectará que o arquivo já foi transferido por download e instalado e ignorará essa tarefa.

Agora você tem uma configuração básica, que pode ser testada implementando o aplicativo no servidor. Dê início ao processo chamando a fase pacote (mvn package). O aplicativo será compilado, empacotado e implementado no servidor e poderá ser alcançado com a URL: http://localhost:8080/{artifactid}/index.html.

Customize a raiz de contexto

Por padrão, o artifactid é usado para nomear a raiz de contexto do aplicativo da web. Em alguns casos, será necessário especificar uma raiz de contexto customizada. Na Listagem 14 eu defini a raiz de contexto como home.

Lista 14. Customizando a raiz de contexto
<deployables>
   <deployable>
       <properties>
           <context>home</context>
       </properties>
   </deployable>
</deployables>

Quando o aplicativo for implementado, o aplicativo da web poderá ser atingido em: localhost:8080/home/index.html.

Especifique os logins de usuário

Agora você tem um processo de implementação bem robusto que faz o download e instala um servidor e implementa o aplicativo em uma raiz de contexto customizada. Mas este é apenas o começo do que o plug-in Cargo pode fazer.

O Cargo realmente entra em ação quando nós começamos a definir as propriedades de configuração. Como eu mencionei anteriormente, essas são as propriedades do contêiner, como porta, protocolo e, ainda mais interessante, os detalhes de login do usuário.

Vamos incluir um usuário em um aplicativo de exemplo e forçar o login no site. Para simplificar, vamos usar o método de autenticação básico, que requer uma configuração bem mínima no aplicativo web.xml. A Listagem 15 mostra a especificação do user-role e uma restrição ao recurso da web WelcomeServlet.

Lista 15. Declarando a função de usuário
<web-app version="3.1"...>

   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Welcome Servlet</web-resource-name>
           <url-pattern>/WelcomeServlet/*</url-pattern>
           <http-method>GET</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>user-role</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>BASIC</auth-method>
       <realm-name>file</realm-name>
   </login-config>

   <security-role>
       <role-name>user-role</role-name>
   </security-role>

</web-app>

É possível configurar o plug-in Cargo para criar um usuário para user-role, que é feito imediatamente no tempo de implementação. A Listagem 16 mostra um nome de usuário e uma senha sendo definidos para user-role. O nome de usuário é user e a senha é user123!.

Lista 16. Definindo um nome de usuário e uma senha
<configuration>
   <properties>
      <cargo.servlet.users>
         user:user1234!:user-role
      </cargo.servlet.users>
   </properties>
</configuration>

O formato da propriedade <cargo.servlet.users> é username:password:role. Ao separar o conjunto com o símbolo de barra vertical, é possível declarar vários usuários para as mesmas funções e para funções diferentes, em uma única propriedade:

username1:password1:role11,...,role1N|username2:password2:role21,...,role2N|...

Com o nome de usuário e a senha designados à função de usuário, agora está tudo pronto para empacotar e implementar o aplicativo. Com apenas um comando — mvn clean package — o aplicativo da web será compilado, empacotado e implementado no contêiner do Liberty. O servidor também será iniciado.

Se você acessar a URL http://localhost:8080/home/WelcomeServlet será exibida uma caixa de login, como é mostrado na Figura 2. Insira o nome de usuário e a senha configurados no plug-in Cargo e clique em Efetuar login para entrar no aplicativo.

Figura 2. O desafio de login
The login challenge
The login challenge

3. Instalar um JAR customizado no repositório local

A maneira tradicional de incluir JARs no projeto é criar um diretório no projeto e assegurar-se de que ele esteja no caminho de classe. Com o Maven não é necessário fazer isso. Em vez de exigir que você localize os JARs em conjunto com o projeto, o Maven armazena-os em um repositório local isolado. Em seguida, o projeto deve especificar uma dependência desses JARs.

O repositório local é preenchido com dependências transferidas por download do repositório Maven central. Esse é o diretório principal do Maven e contém milhares de JARs populares e usados com frequência. Mas e se o JAR que deseja usar não estiver no Maven central? Com certeza, seria possível basear-se na solução tradicional e incluir o JAR diretamente no projeto, mas assim você não se beneficiaria do gerenciamento de dependência do Maven.

Nesse caso, é possível usar o plug-in de instalação do maven para instalar o JAR no repositório Maven local. Primeiro, será necessário fazer o download do plug-in, em seguida, será possível executar seu objetivo install-file. Este exemplo é um pouco diferente dos anteriores porque você não conectará o objetivo a uma fase de ciclo de vida do Maven. Nesse caso, você especificará o objetivo na ferramenta de linha de comando do Maven.

O objetivo install-file requer cinco parâmetros que especifiquem a localização do arquivo JAR, o group e artifactid, seu número de versão e o tipo de pacote. A Listagem 17 mostra a estrutura do comando do Maven.

Lista 17. Instalando um JAR no repositório Maven local
mvn install:install-file 
    -Dfile=PATH/TO/YOUR-JAR.jar 
    -DgroupId=GROUP-ID 
    -DartifactId=ARTIFACT-ID 
    -Dversion=VERSION 
    -Dpackaging=jar

Para o JAR que você deseja instalar, será necessário especificar valores para os parâmetros mostrados. Eles podem ser qualquer coisa que você desejar. Após a execução, você poderá observar que o novo arquivo estará armazenado no repositório Mavem local. Acesse o diretório do repositório /.m2/repository e localize a pasta com o nome GROUP-ID. Se o valor groupId for um nome de domínio reverso, como com.readlearncode, bastará procurar o diretório com e navegar para readlearncode . Este é o local em que você encontrará uma pasta com o número da versão do artefato e o JAR instalado dentro. O local do JAR poderá ser semelhante a este: /.m2/repository/com/readlearncode/4.0/MyJar.jar.

Agora, o JAR está disponível para todos os seus projetos. É possível incluí-lo como uma dependência no POM normalmente, como é mostrado na Listagem 18.

Lista 18. Especificando o JAR como uma dependência
<dependency>
   <groupId>GROUP-ID</groupId>
   <artifactId>ARTIFACT-ID</artifactId>
   <version>VERSION</version>
</dependency>

4. Criar um repositório Maven baseado no GitHub

Clique no botão abaixo para fazer o download do código deste exemplo. Ele contém um aplicativo simples e um arquivo POM com o site-maven-plugin configurado.

Há vários motivos para hospedar um repositório Maven no GitHub, incluindo problemas de licenciamento, privacidade e custo de hospedagem comercial. Independentemente do motivo pelo qual você escolha hospedar um repositório Maven baseado no GitHub, a configuração será fácil.

Para começar, crie uma ramificação em um repositório do GitHub existente e instale os artefatos do projeto diretamente na ramificação. Isso ligará à fase deploy do ciclo de vida do Maven, para que quando o projeto for implementado, o repositório remoto seja atualizado automaticamente.

Inclua as credenciais do GitHub

Depois de criar a ramificação do Maven no repositório do GitHub, será necessário incluir as credenciais do repositório do GitHub no settings.xml do Maven. Esse arquivo geralmente é encontrado no .m2 . Entre os elementos <servers> do settings.xml, é necessário definir um novo servidor e especificar o nome de usuário e a senha. A Listagem 19 demonstra como isso pode ser (observe que eu nomeei meu novo servidor como github).

Lista 19. Configurando um repositório do github como um servidor
 <servers>
	<server>
		<id>github</id>
  		<username>USERNAME_OR_EMAIL</username>
		<password>PASSWORD</password>
	</server>
 </servers>

Autenticação de dois fatores

Se você tiver uma autenticação de dois fatores ativada, será necessário criar um Token de acesso pessoal por meio das Configurações do GitHub. Copie e cole o token diretamente nos elementos <password>. Para garantir uma segurança extra, as senhas podem ser criptografadas seguindo as instruções no website do Maven.

Plug-in do site do Maven

No POM do Maven, você usará o site-maven-plugin do GitHub. A primeira coisa que você precisa fazer é configurar um diretório base que será usado para confirmar arquivos. Comece criando um repositório temporário e localizando-o no diretório target do projeto, como é mostrado na Listagem 20. Para esse exemplo, eu chamei de repo-stage.

Em seguida, como você deseja conectar esse plug-in à fase deploy, é necessário especificar o local do repositório no <altDeploymentRepository> do maven-deploy-plugin. O fragmento de código na Listagem 20 mostra como isso é feito.

Lista 20. Especificando o repositório local alternativo
<plugin>
   <artifactId>maven-deploy-plugin</artifactId>
   <version>2.8.2</version>
   <configuration>
       <altDeploymentRepository>
              Repo.stage::default::file://
              ${project.build.directory}/repo-stage
       </altDeploymentRepository>
   </configuration>
</plugin>

Finalmente, é necessário configurar o site-maven-plugin e conectá-lo à fase deploy. Para fazer isso, forneça ao plug-in o id do servidor GitHub que você criou anteriormente. Também é necessário passar o nome e o proprietário do repositório, a ramificação na qual você está confirmando os artefatos do projeto e um comentário para a confirmação. Também é necessário desativar o Jekyll, para que ele não pense que precisa gerar as páginas do GitHub.

A Listagem 21 mostra uma configuração completa do site-maven-plugin. Observe que o nome de repositório é dependency (se a ramificação não existir, o GitHub a criará).

Lista 21. Configurando o plug-in do site
<plugin>
   <groupId>com.github.github</groupId>
   <artifactId>site-maven-plugin</artifactId>
   <version>0.12</version>
   <configuration>
       <!-- Github settings -->
       <server>github</server>
       <repositoryName>MavenSampler</repositoryName>
       <repositoryOwner>atheedom</repositoryOwner>
       <branch>refs/heads/dependency</branch>
       <message>
         Artifacts for
         ${project.name}/${project.artifactId}/${project.version}
       </message>
       <noJekyll>true</noJekyll>
       <!-- Deployment values -->
       <outputDirectory>
              ${project.build.directory}/repo-stage
       </outputDirectory>
       <includes>
           <include>**/*</include>
       </includes>
   </configuration>
   <executions>
       <execution>
           <phase>deploy</phase>
           <goals>
               <goal>site</goal>
           </goals>
       </execution>
   </executions>
</plugin>

Agora basta apenas executar o comandomvn clean deploy. No console, você verá o plug-in fazendo upload dos arquivos de repositório para a conta do GitHub, criando a confirmação e realizar o push para a ramificação de dependência. A saída do console deve ser semelhante à Figura 3.

Figura 3. Saída do console de uma confirmação bem-sucedida
Console output of successful commit
Console output of successful commit

Para verificar se tudo está funcionado como deveria, visite o repositório do GitHub e selecione a ramificação dependency. Todo os artefatos dos projetos deverão ser exibidos, como é mostrado na Figura 4.

Figura 4. Captura instantânea do repositório Maven no GitHub
Snapshot of the Maven repository in GitHub
Snapshot of the Maven repository in GitHub

Após verificar que seus artefatos estão confirmados com segurança no repositório Maven do GitHub, você poderá compartilhar o novo repositório com outras pessoas que desejam se basear no seu projeto.

Inclua o GitHub como repositório

Para especificar o repositório Maven do GitHub como um repositório remoto para seus próprios projetos, os assinantes precisarão declarar o repositório em seus POMs, como é mostrado na Listagem 22. Em seguida, você especificará os artefatos do novo projeto normalmente, como é mostrado na Listagem 23.

Lista 22. Especificando o GitHub como um repositório remoto
<repositories>
   <repository>
       <id>PROJECT_NAME-dependency</id>
       <url>
              https://raw.github.com/
              GITHUB_USERNAME/PROJECT_NAME/dependency
       </url>
       <snapshots>
           <enabled>true</enabled>
           <updatePolicy>always</updatePolicy>
       </snapshots>
   </repository>
</repositories>
Lista 23. Dependência do projeto
<dependency>
   <groupId>com.readlearncode</groupId>
   <artifactId>maven-sampler</artifactId>
   <version>1.0</version>
</dependency>

Agora você tem um repositório Maven público vazio no qual pode implementar as dependências e compartilhá-las com todo mundo.

5. Mais dicas e truques para economizar tempo

O uso do Apache Maven é tão difundido que encontrar dicas e truques que você ainda não conheça é como procurar ouro. Portanto, eu decidi concluir com um conjunto de dicas que eu acho extremamente úteis. Talvez entre elas você encontre alguns fragmentos que economizarão tempo e frustração.

Um "robô aspirador de pó" para dependências não usadas

Desenvolver é divertido e empolgante, principalmente quando você pode brincar com as novas APIs e tecnologias. O Maven também acelera e facilita a introdução a algo novo: basta copiar e colar a dependência no arquivo POM e pronto. Enquanto desenvolvedores, às vezes, nós somos levados pelo entusiasmo e acabamos esquecendo de remover as dependências não usadas ou temos preguiça de fazer isso. Com o tempo, esse hábito ruim pode ativar o POM e desacelerar as implementações.

Portanto, minha primeira dica é o equivalente do Maven a um robô aspirador de pó, o Roomba. Basta executar o comando na Listagem 24 e o Maven analisará o código do projeto para identificar dependências não usadas.

Lista 24. Identifique as dependências não usadas
dependency:analyze

Limpe o repositório local

Periodicamente, é necessário limpar o diretório Maven — talvez devido à distorção ou quando o IDE desacelera muito a indexação. Seja qual for o motivo, é possível remover todo o lixo executando o código na Listagem 25.

Lista 25. Limpando o repositório local
mvn dependency:purge-local-repository

Esse código limpará e, em seguida, fará o download automaticamente de todas as dependências do projeto atual. Será como recriar o projeto e ele estará pronto para superar seu desempenho novamente.

Coloque um registro de data e hora!

Incluir um registro de data e hora na construção pode ser muito útil. O Maven 2 introduziu a variável de construção maven.build.timestamp, que denota o início da construção. É possível usar essa variável em qualquer lugar no POM com a variável ${maven.build.timestamp}.

O registro de data e hora é formatado usando a classe Java SimpleDateFormat e declarado com a propriedade <maven.build.timestamp.format>. A Listagem 26 mostra um exemplo de como fazer isso.

Lista 26. Formato do registro de data e hora
<properties>
    <maven.build.timestamp.format>
        yyyy-MM-dd'T'HH:mm:ss'Z'
    </maven.build.timestamp.format>
</properties>

Propriedades de eco

Você já desejou saber o valor de uma propriedade do Maven? Em vez de adivinhar, você pode ter certeza com o maven-antrun-plugin. Essa pequena ferramenta interessante emite o eco de qualquer propriedade que você passar a ela no console.

Na Listagem 27, o objetivo run do antrun é conectado à fase validate do Maven (a primeira fase do ciclo de vida padrão) e usa o elemento <echo> na seção de configuração para emitir os valores da propriedade.

Lista 27. Emita o eco de uma propriedade no console
<plugin>
   <groupId>org.apache.maven.plug-ins</groupId>
   <artifactId>maven-antrun-plugin</artifactId>
   <version>1.1</version>
   <executions>
       <execution>
           <phase>validate</phase>
           <goals>
               <goal>run</goal>
           </goals>
           <configuration>
               <tasks>
                   <echo>
                        settings.localRepository = ${settings.localRepository}
                   </echo>
                   <echo>
                        project.build.directory = ${project.build.directory}
                   </echo>
               </tasks>
           </configuration>
       </execution>
   </executions>
</plugin>

Agora, basta usar mvn validate para executar a fase validate e ver o valor da propriedade emitido no console.

Conclusão

O Maven é muito mais que apenas uma ferramenta de construção, graças aos plug-ins que simplificam e automatizam uma ampla variedade de tarefas de desenvolvimento. Neste artigo, eu apresentei uma variedade de plug-ins e ofereci dicas de como usá-los para gerar um ciclo de vida de desenvolvimento mais efetivo e produtivo. Para saber ainda sobre o Maven e seu ciclo de vida de projeto, consulte "Cinco coisas que você não sabia sobre o Apache Maven" que eu atualizei recentemente para o Maven 3.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=1050590
ArticleTitle=Cinco coisas que você não sabia sobre...: Plug-ins do Apache Maven
publish-date=10042017