Posts Tagged ‘Maven’

Apache Maven – Relatórios

Posted in Avaliação on May 24th, 2009 by Fábio Queiroz – Be the first to comment

Os relatórios gerados pelo Maven são recursos disponíveis para visualizar o estado atual de um projeto. Existem vários relatórios disponíveis.

Relatórios sobre o Projeto

O Maven não mantém um conjunto de relatórios padrões para geração. Todos os relatórios são “plugáveis”. Isso significa que a instituição pode definir quais relatórios podem ser gerados para o site de seu projeto.

Os relatórios comumente utilizados são:

A lista dos plugins disponíveis para o Maven pode ser encontrada em:

Changelog

Este relatório é utilizado para verificar os detalhes das recentes alterações em código (ação de “commit”) realizadas pelos membros sobre os arquivos do projeto em um intervalo de tempo definido.

Possui três finalidades:

  • Changelog: apresentar informações sobre os arquivos do projeto sincronizados por cada membro no CVS;
  • Dev Activity: apresentar informações consolidadas sobre a sincronização dos arquivos no CVS pelos membros do projeto;
  • File Activity: apresentar informações consolidadas sobre a sincronização dos arquivos no CVS.

Por padrão, são apresentados os resultados referentes aos últimos 30 dias.

Este relatório é integrado com o CVS e gerado automaticamente.

Para mais detalhes, clique aqui.

Changes

Este relatório é utilizado para verificar os detalhes das versões do projeto (ação “Tag as Version”).

As informações apresentadas neste relatório são definidas manualmente no arquivo “changes.xml”.

É possível definir endereços de e-mail para receber uma notificação das alterações realizadas (opcional).

Para mais detalhes, clique aqui.

Checkstyle

Este relatório é utilizado para verificar o estilo de codificação dos arquivos.

Por padrão, é utilizado o estilo de codificação sugerido pela SUN (tudo é capturado como “Errors”). No entanto, é possível personalizar os tipos de checagem.

As informações apresentadas nesse relatório devem ser corrigidas pelos programadores.

Para mais detalhes, clique aqui.

CPD

Este relatório é utilizado para verificar a existência de códigos duplicados.

As informações apresentadas nesse relatório devem ser corrigidas pelos programadores.

Para mais detalhes, clique aqui.

PMD

Este relatório é utilizado para verificar a existência de possíveis bugs, códigos não usados, códigos que podem ser substituídos por códigos mais otimizados, códigos desnecessários e códigos duplicados.

As informações apresentadas nesse relatório devem ser corrigidas pelos programadores.

Para mais detalhes, clique aqui.

Dashboard

Este relatório agrega as informações geradas pelos relatórios Checkstyle, Cobertura, Surefire, PMD e CPD.

Para que este relatório seja gerado, é necessário adicionar a linha de código abaixo:

mvn site -Djava.awt.headless=true

Para mais detalhes, clique aqui.

FindBugs

Este relatório é utilizado para apresentar os possíveis problemas (bugs) no código, separados em categorias como:

  • Código malicioso
  • Má Prática
  • Internacionalização
  • Performance, dentre outras.

As informações apresentadas nesse relatório devem ser corrigidas pelos programadores.

Para mais detalhes, clique aqui.

JavaDocs

Este relatório apresenta a documentação gerada para todas os pacotes, classes e interfaces existentes no projeto.

Para mais detalhes, clique aqui.

JDepend

Este relatório é utilizado para verificar as métricas de qualidade para cada pacote de código do projeto, a fim de medir a qualidade do design em termos de extensibilidade, reusabilidade e manutenibilidade para controlar as dependências entre os pacotes.

As principais informações relativas aos pacotes são:

  • Number of Classes: número total de classes;
  • Concrete Classes: número total de classes concretas;
  • Abstract Classes: número total de classes abstratas e interfaces;
  • Afferent Couplings: qual o impacto de alterações nas classes do atual pacote para as classes dos outros pacotes do projeto?
  • Efferent Couplings: qual o impacto de alterações nas classes dos outros pacotes do projeto nas classes do pacote atual?
  • Abstractness: porcentagem relativa ao número de classes abstratas do pacote;
  • Instability: quanto mais o pacote atual depende de outros pacotes do sistema, mais instável ele é;
  • Distance: a relação entre o pacote e “abstractness” e “instability”, ou seja, o pacote é mais abstrato (0) ou instável (1);
  • Cycles: pacotes ciclicamente dependentes.

A intenção desse relatório é mostrar o quanto os pacotes e classes são interdependentes. A principal causa dessa dependência é o fato de existir classes concretas utilizando outras classes concretas de pacotes distintos.

Para mais detalhes, clique aqui.

Tag List

Este relatório é utilizado para verificar as marcações “TODO” existentes no código. É possível personalizar as marcações a serem verificadas (marcações “FIXME” e “@deprecated”, por exemplo).

Para mais detalhes, clique aqui.

Apache Maven – Projeto POM, Projeto Base e Site

Posted in Tutorial on May 24th, 2009 by Fábio Queiroz – Be the first to comment

Neste artigo faremos uma primeira configuração do POM, já que a configuração do Maven foi tratada em outro artigo.

Todo projeto deve possuir um POM básico para que você possa economizar linhas de arquivo XML e padronizar / centralizar as informações relevantes do seu projeto / cliente.

O trecho de código abaixo apresenta um arquivo pom.xml básico.

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/maven-v4_0_0.xsd">

<modelVersion>4.0.0</modelVersion>
<properties>
<prop.resourcesDir>C:/apache-maven-2.1.0/www/resources</prop.resourcesDir>
<prop.url>http://www.suaempersa.com.br</prop.url>
<prop.organization>Sua Empresa</prop.organization>
<prop.roleJavaDeveloper>Java Developer</prop.roleJavaDeveloper>
</properties>
<groupId>suaempresa</groupId>
<artifactId>pom</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
</project>

As informações “groupId”, “artifactId” e “version” são imprescindíveis para identificar o POM do seu projeto. A informação “packaging” identifica que tipo de artefato está definido. Neste caso, o POM é um artefato “pom”. Os tipos de artefatos são:

  • pom
  • jar
  • maven-plugin
  • ejb
  • war
  • ear
  • rar
  • par

Estamos definindo este primeiro POM para que ele seja utilizado como herança para outros projetos. Sim, vamos padronizar e reaproveitar configurações.

Criar projeto POM no Maven

Crie o diretório C:\apache-maven-2.1.0\projects\pom. Neste diretório, coloque o arquivo referente ao POM base (pom.xml) que utilizaremos em nosso projetos.

Abra uma janela de comando, vá até o diretório criado anteriormente e digite “mvn install”. Este comando definirá o projeto POM no repositório do Maven.

Instalar projeto POM

Instalar projeto POM

Veja que o foi criado o diretório C:\apache-maven-2.1.0\repo\suaempresa\pom\1.0 e neste existe o arquivo pom-1.0.xml.

Criar Projeto Base

Agora que já temos o projeto POM no repositório do Maven, vamos criar um primeiro projeto Java. No diretório C:\apache-maven-2.1.0\projects, digite o comando abaixo.

mvn archetype:create -DgroupId=suaempresa -DartifactId=base

Espere pelo resultado de sucesso.
Criar Projeto Base
Este comando criará uma estrutura padrão de diretórios como abaixo.
Diretórios do projeto Base
A pasta “main\java\suaempresa” conterá a classe “App.java”. Este é um arquivo Java simples.


package suaempresa;

/**
* Hello world!
*
*/
public class App
{
public static void main( String[] args )
{
System.out.println( "Hello World!" );
}
}

A pasta “test\java\suaempresa” conterá a classe “AppTest.java”. Este é um arquivo de teste do JUnit simples.


package suaempresa;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

/**
* Unit test for simple App.
*/
public class AppTest
extends TestCase
{
/**
* Create the test case
*
* @param testName name of the test case
*/
public AppTest( String testName )
{
super( testName );
}

/**
* @return the suite of tests being tested
*/
public static Test suite()
{
return new TestSuite( AppTest.class );
}

/**
* Rigourous Test <img src="http://s.wordpress.com/wp-includes/images/smilies/icon_smile.gif" alt=":-)" class="wp-smiley">
*/
public void testApp()
{
assertTrue( true );
}
}

O arquivo pom.xml deste projeto será criado com algumas configurações padrão. Veja abaixo.


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>suaempresa</groupId>
<artifactId>base</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>base</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

A partir desse ponto temos artefatos para começar a customizar nosso projeto.

Adicionar Customizações

Edite o arquivo pom.xml do projeto POM (o projeto que contém somente o arquivo pom.xml), nosso projeto que contém o POM comum aos demais projetos.

O trecho de código abaixo deve ser adicionado após a tag “packaging”.


<reporting>
<outputDirectory>${prop.siteDir}/site/</outputDirectory>
</reporting>

Mude o valor da tag “version” para 1.1.

Vá ao diretório deste projeto e digite “mvn install”. Uma nova versão do POM será adicionada no repositório do Maven.
Atualizar projeto POM para 1.1
Edite o arquivo pom.xml do projeto Base. Adicione o trecho de código a seguir abaixo da tag “modelVersion”.

<properties>
<prop.siteDir>C:/apache-maven-2.1.0/www/Base</prop.siteDir>
<prop.srcMainJava>src/main/java</prop.srcMainJava>
</properties>
<parent>
<groupId>suaempresa</groupId>
<artifactId>pom</artifactId>
<version>1.1</version>
</parent>

Com este código estamos adicionando propriedades específicas para o projeto e atualizando a versão do POM.

O trecho de código abaixo deve ser adicionado após a tag “dependencies”.


<build>
<directory>${prop.siteDir}</directory>
<sourceDirectory>${prop.srcMainJava}</sourceDirectory>
<outputDirectory>${prop.siteDir}/target/classes</outputDirectory>
</build>

Com este código estamos definindo os diretórios de saída dos artefatos que serão gerados.

Bom, definimos um monte de coisa mas ainda não vimos nada “palpável”. Então vamos começar com algo interessante: um site.

Vá ao diretório do projeto Base (C:\apache-maven-2.1.0\projects\base) e digite o comando “mvn site”. O Maven comecará a criar uma estrutura com arquivos HTML que será o site do projeto, que conterá documentações e relatórios.
Criar site do projeto Base
O Maven criará a estrutura de diretórios como mostrado abaixo.
Estrutura de diretórios do site
O site visto no Firefox seria assim.
Site do projeto Base
As informações básicas geradas para o projeto contém os tópicos:

  • About
  • Continuous Integration
  • Dependencies
  • Issue Tracking
  • Mailing Lists
  • Plugin Management
  • Project License
  • Project Summary
  • Project Team
  • Source Repository

Mas por enquanto, poucos tem informações. Veja o “Project Summary”.
Sumário do projeto Base
Bom, para este artigo já temos informações suficientes para você ter uma idéia do que o Maven é capaz. No próximo artigo, falaremos e demonstraremos alguns dos relatórios. Até lá, deixe seus comentários sobre este artigo.