Maven 3 Tutorial

10 comandos valiosos no Maven que você precisa conhecer

noreply@blogger.com (Jony Ferreira) — Thu, 20 Feb 2014 20:55:00 +0000

Ao estudar um pouco mais o Maven identifiquei alguns comandos valiosos que podem ser úteis para avaliação do status atual do projeto. Vale a pena executar cada um deles para ver o que acontece!

1)Exibe as atualizações existentes para as dependências do projeto.

mvn versions:display-dependency-updates

Resultado semelhante a:
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] commons-io:commons-io ..................................... 2.1 -> 2.4
[INFO] commons-logging:commons-logging ....................... 1.1.1 -> 1.1.3

2) Exibe as atualizações existentes para os plugins configurados no projeto.

mvn versions:display-plugin-updates
...
[INFO] All plugins with a version specified are using the latest versions.
[INFO]
[WARNING] The following plugins do not have their version specified:
[WARNING] maven-clean-plugin .......................... (from super-pom) 2.5
[WARNING] maven-compiler-plugin ....................... (from super-pom) 3.1
[WARNING] maven-deploy-plugin ......................... (from super-pom) 2.7
[WARNING] maven-install-plugin ........................ (from super-pom) 2.4
[WARNING] maven-jar-plugin ............................ (from super-pom) 2.4
[WARNING] maven-resources-plugin ...................... (from super-pom) 2.6
[WARNING] maven-site-plugin ........................... (from super-pom) 3.3
[WARNING] maven-surefire-plugin ...................... (from super-pom) 2.15
[INFO]
[WARNING] Project does not define minimum Maven version, default is: 2.0
[INFO] Plugins require minimum Maven version of: 2.2.1
[INFO] Note: the super-pom from Maven 3.0.4 defines some of the plugin
[INFO] versions and may be influencing the plugins required minimum Maven
[INFO] version.
[INFO]
[ERROR] Project does not define required minimum version of Maven.
[ERROR] Update the pom.xml to contain
[ERROR]
[ERROR] 2.2.1
[ERROR]
[INFO]
[INFO] Require Maven 2.0.2 to use the following plugin updates:
[INFO] maven-site-plugin ........................................ 2.0-beta-7
[INFO]
[INFO] Require Maven 2.0.6 to use the following plugin updates:
[INFO] maven-clean-plugin .............................................. 2.5
[INFO] maven-deploy-plugin ............................................. 2.7
[INFO] maven-install-plugin ............................................ 2.4
[INFO] maven-jar-plugin ................................................ 2.4
[INFO] maven-resources-plugin .......................................... 2.6
[INFO] maven-site-plugin ............................................. 2.0.1
[INFO] maven-surefire-plugin ......................................... 2.4.3
[INFO]
[INFO] Require Maven 2.0.9 to use the following plugin updates:
[INFO] maven-compiler-plugin ........................................... 3.1
[INFO] maven-surefire-plugin .......................................... 2.15
[INFO]
[INFO] Require Maven 2.1.0 to use the following plugin updates:
[INFO] maven-site-plugin ............................................. 2.1.1
[INFO]
[INFO] Require Maven 2.2.0 to use the following plugin updates:
[INFO] maven-site-plugin ............................................... 3.0
[INFO]
[INFO] Require Maven 2.2.1 to use the following plugin updates:
[INFO] maven-site-plugin ............................................... 3.3

3) Exibe a árvore detalhada de dependencias

mvn dependency:tree -Ddetail
...
[INFO] br.com.maven3.tutorial:hot.commands:jar:0.0.1-SNAPSHOT
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-io:commons-io:jar:2.1:compile

4)Exibe a lista de dependencias do projeto

mvn dependency:list

...
[INFO] commons-io:commons-io:jar:2.1:compile
[INFO] commons-logging:commons-logging:jar:1.1.1:compile

5) Exibe a versão completa do pom.

mvn help:effective-pom

6) Exibe a configuração do maven

mvn help:effective-settings

7)Exibe as variáveis de ambiente e de sistema

mvn help:system

8)Exibe o classpath das dependencias do projeto

mvn dependency:build-classpath

9)Exibe quais dependências são desnecessárias

mvn dependency:analyze
...
[WARNING] Unused declared dependencies found:
[WARNING] commons-logging:commons-logging:jar:1.1.1:compile
[WARNING] commons-io:commons-io:jar:2.1:compile

10)Exibe as dependências que estão duplicadas no projeto.

dependency:analyze-duplicate

...
[INFO] List of duplicate dependencies defined in in your pom.xml
:
o commons-io:commons-io:jar

Considerações Finais

Embora tais comandos possam informar que plugins ou dependências estejam desatualizados vale sempre a pena pensar duas vezes antes de aplicar atualizações que possam gerar efeitos colaterais.

Atualizações devem ser seguidas de muitos testes. Testes devem abranger todas as áreas envolvidas do projeto. O tempo necessário para aplicar tais atualizações e/ou possíveis correções devem ser contemplados.

Ebooks completos sobre Maven

noreply@blogger.com (Jony Ferreira) — Fri, 22 Feb 2013 03:52:00 +0000

Pesquisando na internet encontrei alguns ebooks sobre Maven. Caso tenha mais alguma sugestão por favor informar.

Seguem os links:

Maven: The Complete Reference

APACHE MAVEN TUTORIAL
Simply Easy Learning by tutorialspoint.com

Better Builds with Maven

Veja como configurar o seu projeto web para executar no Jetty

noreply@blogger.com (Jony Ferreira) — Wed, 24 Aug 2011 01:37:00 +0000

Após exemplificar como configurar o seu projeto web para executar no Tomcat chegou a vez de explicar como fazer isto no Jetty.

Para executar diretamente o jetty basta adicionar o trecho abaixo entre as das tags <build><plugins></plugins></build>.

<plugin>  <groupId>org.mortbay.jetty</groupId>  <artifactId>maven-jetty-plugin</artifactId>  <version>6.1.26</version>  <configuration>     <!-- Delete this block to have Jetty run default port (8080) -->     <connectors>        <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">           <port>9090</port>        </connector>     </connectors>     <!-- force friendly name instead of artifact name + version -->     <contextPath>${project.build.finalName}</contextPath>     <!-- Where the BeanManager is constructed. This is where you'll declare datasources. -->     <jettyEnvXml>${project.basedir}/src/test/resources/jetty-env.xml</jettyEnvXml>     <!-- This parameter will auto-deploy modified classes. -->     <!-- You can save changes in a file or class and refresh your browser to view the changes. -->     <scanIntervalSeconds>3</scanIntervalSeconds>  </configuration></plugin>

Como pode ser visto não é necessário configurar mais nada para executar o Jetty. Veja que através da execução do comando jetty:run o Maven irá instalar em seu repositório local todas as bibliotecas necessárias para execução do Jetty. Após a execução deste comando o projeto estará disponível no endereço http://localhost:9090/${project.build.finalName}.
Para maiores informações sugiro verificar a documentação do plugin.

Veja como configurar o seu projeto web para executar no Tomcat

noreply@blogger.com (Jony Ferreira) — Wed, 24 Aug 2011 00:47:00 +0000

Existe uma forma muito simples de executar o Tomcat configurado diretamente para o seu projeto. Achei esta forma muito útil e resolvi compartilhar. Faça o teste e depois comente!

Para executar diretamente o tomcat basta adicionar o trecho abaixo entre as das tags <build><plugins></plugins></build>.

<!-- Embedded Tomcat (package tomcat:run) --><!-- Standalone Tomcat (package tomcat:deploy) --><plugin>   <groupId>org.codehaus.mojo</groupId>   <artifactId>tomcat-maven-plugin</artifactId>   <version>1.0</version>   <configuration>      <path>/${project.build.finalName}</path>      <!-- Embedded port -->      <port>9090</port>      <!--         The default authentication credentials for remote deployment are username "admin" with no password To         override credentials, define a server in settings.xml and activate it using the <server> element      -->      <url>http://localhost:9090/manager</url>   </configuration></plugin>

Como pode ser visto não é necessário configurar mais nada para executar o Tomcat. Veja que através da execução do comando tomcat:run o Maven irá instalar em seu repositório local todas as bibliotecas necessárias para execução do Tomcat. Após a execução deste comando o projeto estará disponível no endereço http://localhost:9090/${project.build.finalName}. Este nome pode ser alterado conforme a sua necessidade.

Não tenho muito a mais falar pois o resultado final já fala sozinho.

Para maiores informações sugiro verificar a documentação do plugin.

Converta um projeto web do Eclipse para o Maven

noreply@blogger.com (Jony Ferreira) — Wed, 15 Jun 2011 21:32:00 +0000

Nem sempre começamos um projeto no Maven, não é verdade? Por este motivo ensinarei como converter um projeto Web, que fora criado diretamente no Eclipse, para que o mesmo seja compatível com o Maven e use todas as suas possibilidades.

Antes de mais nada irei explicar como criar um projeto web no Eclipse…

O primeiro passo é criar um novo projeto, através do menu File / New. A tela abaixo será exibida, para facilitar digitei a palavra web para encontrar a opção Dynamic Web Project.

Agora é necessário dar um nome ao projeto e pressionar o botão Finish.

Como você pode perceber, o Eclipse criará um novo projeto Web. Veja que o código Java ficou na pasta src e código fonte web ficou na pasta WebContent.

Até então o pom.xml do Maven não foi criado. Para criar o pom basta clicar no nome do projeto com o botão direito do mouse e selecionar a opção Maven / Enable Dependency Management.

A próxima tela exibida pelo Eclipse é a tela de configurações básicas de conversão. Como se trata de um projeto web é necessário alterar o parâmetro Packaging para war. Após isto pressione o botão Finish.

Pronto, agora temos o “esqueleto” pom.xml. Deve ser semelhante ao código 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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>EclipseToMaven</groupId>
  <artifactId>EclipseToMaven</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>war</packaging>
</project>

Infelizmente o trecho de código acima não é suficiente para “entender” o projeto criado no Eclipse. Altere este trecho de código para que fique semelhante a:

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>EclipseToMaven</groupId>
  <artifactId>EclipseToMaven</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>war</packaging>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <warSourceDirectory>WebContent</warSourceDirectory>
        </configuration>
      </plugin>
    </plugins>
    <sourceDirectory>src</sourceDirectory>
  </build>
</project>

Agora para ver se a conversão vai funcionar execute o comando

mvn package

Não podia esquecer de dizer que caso o seu projeto seja um projeto com muitas dependências você terá que adicioná-las como dependências do Maven para que o seu código compile através do pom.xml. As pastas build pelo Eclipse fora da pasta target(criada pelo maven) será ignorada.

E aí? Conseguiu, qualquer dúvida deixe um comentário!

Seam3 + Maven + Tomcat – Isto é possível?

noreply@blogger.com (Jony Ferreira) — Fri, 10 Jun 2011 01:58:00 +0000

Esta é uma dúvida daqueles que ainda não testaram o Seam 3 ou daqueles que ainda não migraram para a nova versão que foi lançada. Assim como você que está lendo esta postagem também descobri que isto é possível e por sinal muito simples a princípio.

Para inicio de conversa iremos usar um template(archetype) já existente o qual irá facilitar boa parte do projeto. Para maiores informações sobre templates leia Dicas para usar templates de projetos pré-configurados no Maven - Maven Archetypes.

Execute o comando abaixo para criar o seu projeto, (veja que usei -DgroupId=br.com.maven3.tutorial -DartifactId=projeto.exemplo.seam3 mas você pode alterar isto):

mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=jboss-jsf-weld-servlet-webapp -DarchetypeGroupId=org.jboss.weld.archetypes -DarchetypeRepository=central -DgroupId=br.com.maven3.tutorial -DartifactId=projeto.exemplo.seam3

Após a execução com sucesso veja que a pasta projeto.exemplo.seam3 foi criada.

Ótimo não? Ótimo que nada! Vamos ver o que ainda é possível…

Este template de projeto foi projetado para funcionar com Tomcat e também com o Jetty. Para maiores informações veja no próprio site do Seam.

Agora vamos para mágica(não é mágica é maven mesmo facilitando a nossa vida):

Execute o comando para gerar o pacote: mvn package

Para finalizar, vamos executar o projeto criado, mas para isto vamos apenas executar o comando:

mvn tomcat:run

Isto mesmo, o danado do Maven fez o Download do Tomcat e iniciou na porta 9090.

Acesse o endereço http://localhost:9090/projeto.exemplo.seam3 e verá a tela:

Sei que pode estar pensando que isto foi uma mágica de tão simples mas sugiro aprender um pouco mais do Maven, Seam e finalizar lendo o arquivo pom.xml gerado. Este template de projeto criado está com o pom.xml comentado, vale a pena conferir.

Na verdade o template é apenas um exemplo para implementação do Weld. Weld é uma implementação de referência(RI) do JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI). CDI é o padrão Java para injeção de dependência e de gestão do ciclo de vida contextual. Qualquer servidor de aplicações Java EE 6-compatível oferece suporte a JSR-299.

Para os que estão evoluindo do Seam 2 para o Seam 3 segue um diagrama que ilustra o relacionamento entre Seam 2, Seam 3 e JSR-299:

Resumindo:

CDI é uma especificação JCP incluída no Java EE
Weld é uma implementação do CDI
Seam 3 é um conjunto de módulos os quais estendem o CDI para complementar as ferramentas já fornecidas pelo Java EE 6.

Após saber mais um pouco sugiro conhecer os módulos existentes no Seam 3 em http://seamframework.org/Seam3/Status#H-Modules. Depois vá mudando o exemplo anterior apresentado para testar os seus conhecimentos adquiridos. Boa Sorte!

Qualquer dúvida, sugestão, ou até mesmo que não tenha conseguido executar, por favor deixe o seu recado.

Guia de referência rápida para comandos Maven

noreply@blogger.com (Jony Ferreira) — Fri, 03 Jun 2011 03:18:00 +0000

O Maven possui uma vasta lista de comandos que, sinceramente, não guardo todos na memória.

Para facilitar a sua vida e a minha também imaginei: por que não criar uma página de referência com os principais comandos existentes? Assim podemos acessá-la sempre que for necessário para lembrar de alguns comandos até que todos estejam “decorados”.

Espero que seja útil e que estejam todos funcionando em seus computadores! Qualquer dúvida, sugestão é só falar que melhoramos a lista.

Fique a vontade para adicionar novos comandos na seção de comentários.

Veja também o link Super dicas para início rápido no uso do Maven já que o mesmo é um complemento importante para esta lista. Como esta postagem é um mini-guia rápido do Maven alguns comandos estão redundantes nas duas postagens.

1. Para compilar

mvn compile

2. Para compilar offline

mvn –o compile

3. Para criar os pacotes

mvn package

4. Instalar o pacote nos respectivos repositórios

mvn install

5. Limpar a pasta target

mvn clean

6. Gerar um projeto eclipse(normalmente prefiro recriar)

mvn eclipse:clean eclipse:eclipse

7. Gerar um projeto eclipse baixando os códigos-fonte das dependências

mvn eclipse:clean eclipse:eclipse –DdownloadSources=true

7.1. Gerar um projeto eclipse baixando os códigos-fonte assim como o javadoc das dependências

mvn eclipse:clean eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true

8. Executar os testes unitários

mvn test

9. Executar os testes unitários apenas informando no console os resultados dos testes

mvn -Dsurefire.useFile=false test

10. Executar um teste específico

mvn test –Dtest=br.com.maven3.tutorial.tests.suaClasseDeTestes

11. Ignorar os testes ao gerar um pacote

mvn package -Dmaven.test.skip=true

12. Ignorar os testes ao instalar um pacote

mvn install -Dmaven.test.skip=true

13. Gerar um projeto web baseado em um template(Leia mais sobre templates em Dicas para usar templates de projetos pré-configurados no Maven - Maven Archetypes)

mvn archetype:create -DgroupId=br.com.projeto.exemplo -DartifactId=projeto-web -DarchetypeArtifactId=maven-archetype-webapp

14. Gerar site de documentação para o projeto

mvn site

15. Gerar Javadoc

mvn javadoc:javadoc

16. Para ver qual é o pom.xml que o Maven entende(veja o link Qual é a estrutura padrão de diretórios e arquivos no Maven?)

mvn help:effective-pom

17. Como executar um profile

mvn <comando> –P profile1

18. Como executar 2 profiles

mvn <comando> –P profile1 –P profile2

19. Como ignorar um profile e executar outro profile

mvn <comando> –P !profile1 –P profile2

20. Como recriar um projeto web aberto na pasta target

mvn clean package war:exploded

21. Como executar o Sonar(Aprenda mais sobre o Sonar em Aprenda como melhorar a qualidade do código usando o Sonar

mvn sonar:sonar

22. Exibir todas as dependências e dependências transitivas, ajudando a identificar conflitos

mvn dependency:tree

23. Exibir todas as dependências transitivas para um pacote, ajudando a identificar conflitos

mvn -X <nome_pacote>

24. Fazer download dos códigos fontes independentes de IDE

mvn dependency:sources

Qual é a estrutura padrão de diretórios e arquivos no Maven?

noreply@blogger.com (Unknown) — Fri, 03 Jun 2011 02:00:00 +0000

O uso de diretórios pré-configurados pelo Maven permite que novos usuários se familiarizem imediatamente com um novo projeto Maven.

Podemos dizer que é análogo a uma mudança aparência de um site onde conhecemos a sua estrutura e sabemos como usá-lo, mesmo após mudando apenas o modelo(template).

Irei informar os diretórios e em quais contextos os mesmos se aplicam dentro da estrutura do projeto.

src/main/java - Diretório onde está o código fonte Java da Aplicação e/ou Biblioteca
src/main/resources - Arquivos de configuração e outros arquivos devem ficar nesta pasta
src/main/filters - Pasta onde contém arquivos que podem ser configurados conforme o ambiente e/ou profile usado
src/main/assembly - Pasta que possui arquivos descritores de configuração da construção de um determinado artefato
src/main/config - Arquivos de configuração
src/main/webapp - Pasta para conteúdo Web. Aqui se encontra todos os arquivos fonte da parte web.
src/test/java - Pasta que contém os arquivos de testes unitários
src/test/resources - Pasta com arquivos que serão utilizados pelas classes de testes unitários
src/test/filters - Análogo ao diretório src/main/filters só que usado apenas para testes.
src/site - Diretório onde está a configuração do site de documentação do projeto.
LICENSE.txt Arquivo de licença do projeto
NOTICE.txt Avisos e atribuições necessárias para uso de bibliotecas as quais o projeto depende.
README.txt Arquivo Leia-me do projeto.

Na pasta raiz do projeto inicialmente existe apenas o pom.xml assim como arquivos secundários tais como propriedades, build.xml(caso esteja também usando o Ant) e os diretórios src e target(este último será gerado apenas após a execução de alguns comandos tais como mvn compile, mvn package, mvn install etc).

Conforme descrito o src é onde está todo o código fonte necessário para o projeto. A pasta target é o local onde todos os artefatos necessários para a criação dos pacotes do projeto serão gerados. Nunca versione(CVS,SVN,Clearcase etc) esta pasta. Ela pode ser apagada sem problemas e o Maven também pode fazer isto(mvn clean).

Usamos como base um projeto com códigos fonte Java porém podem existir outras pastas de arquivo fonte tais como Antlr(src/main/antlr) e Groovy(src/main/groovy).

Sugiro que use as configurações conforme especificado acima e será possível, como exemplo, criar a seguinte estrutura de projeto para um projeto war(vamos dizer que seu projeto esteja na pasta F:\projetos\maven.default):

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>br.com.maven3.tutorial</groupId>
  <artifactId>maven.default</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</project>

O comando mvn help:effective-pom exibe uma versão extendida do arquivo pom.xml como o Maven realmente entende. Isto irá ajudar no entendimento do que realmente é configurado automaticamente pelo Maven para você. Perceba que apenas como 7 linhas do pom.xml se transformam em mais de 237 linhas!

<?xml version="1.0"?>

<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <modelVersion>4.0.0</modelVersion>

  <groupId>br.com.maven3.tutorial</groupId>

  <artifactId>maven.default</artifactId>

  <version>1.0</version>

  <packaging>war</packaging>

  <repositories>

    <repository>

      <id>Codehaus Snapshots</id>

      <url>nexus.codehaus.org</url>

    </repository>

    <repository>

      <snapshots>

        <enabled>false</enabled>

      </snapshots>

      <id>central</id>

      <name>Maven Repository Switchboard</name>

      <url>http://repo1.maven.org/maven2</url>

    </repository>

  </repositories>

  <pluginRepositories>

    <pluginRepository>

      <id>Codehaus Snapshots</id>

      <url>nexus.codehaus.org</url>

    </pluginRepository>

    <pluginRepository>

      <releases>

        <updatePolicy>never</updatePolicy>

      </releases>

      <snapshots>

        <enabled>false</enabled>

      </snapshots>

      <id>central</id>

      <name>Maven Plugin Repository</name>

      <url>http://repo1.maven.org/maven2</url>

    </pluginRepository>

  </pluginRepositories>

  <build>

    <sourceDirectory>F:\projetos\maven.default\src\main\java</sourceDirectory>

    <scriptSourceDirectory>F:\projetos\maven.default\src\main\scripts</scriptSourceDirectory>

    <testSourceDirectory>F:\projetos\maven.default\src\test\java</testSourceDirectory>

    <outputDirectory>F:\projetos\maven.default\target\classes</outputDirectory>

    <testOutputDirectory>F:\projetos\maven.default\target\test-classes</testOutputDirectory>

    <resources>

      <resource>

        <directory>F:\projetos\maven.default\src\main\resources</directory>

      </resource>

    </resources>

    <testResources>

      <testResource>

        <directory>F:\projetos\maven.default\src\test\resources</directory>

      </testResource>

    </testResources>

    <directory>F:\projetos\maven.default\target</directory>

    <finalName>maven.default-1.0</finalName>

    <pluginManagement>

      <plugins>

        <plugin>

          <artifactId>maven-antrun-plugin</artifactId>

          <version>1.3</version>

        </plugin>

        <plugin>

          <artifactId>maven-assembly-plugin</artifactId>

          <version>2.2-beta-5</version>

        </plugin>

        <plugin>

          <artifactId>maven-dependency-plugin</artifactId>

          <version>2.1</version>

        </plugin>

        <plugin>

          <artifactId>maven-release-plugin</artifactId>

          <version>2.0</version>

        </plugin>

      </plugins>

    </pluginManagement>

    <plugins>

      <plugin>

        <artifactId>maven-clean-plugin</artifactId>

        <version>2.4.1</version>

        <executions>

          <execution>

            <id>default-clean</id>

            <phase>clean</phase>

            <goals>

              <goal>clean</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-install-plugin</artifactId>

        <version>2.3.1</version>

        <executions>

          <execution>

            <id>default-install</id>

            <phase>install</phase>

            <goals>

              <goal>install</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-resources-plugin</artifactId>

        <version>2.4.3</version>

        <executions>

          <execution>

            <id>default-resources</id>

            <phase>process-resources</phase>

            <goals>

              <goal>resources</goal>

            </goals>

          </execution>

          <execution>

            <id>default-testResources</id>

            <phase>process-test-resources</phase>

            <goals>

              <goal>testResources</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-surefire-plugin</artifactId>

        <version>2.7.1</version>

        <executions>

          <execution>

            <id>default-test</id>

            <phase>test</phase>

            <goals>

              <goal>test</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-compiler-plugin</artifactId>

        <version>2.3.2</version>

        <executions>

          <execution>

            <id>default-testCompile</id>

            <phase>test-compile</phase>

            <goals>

              <goal>testCompile</goal>

            </goals>

          </execution>

          <execution>

            <id>default-compile</id>

            <phase>compile</phase>

            <goals>

              <goal>compile</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-war-plugin</artifactId>

        <version>2.1.1</version>

        <executions>

          <execution>

            <id>default-war</id>

            <phase>package</phase>

            <goals>

              <goal>war</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-deploy-plugin</artifactId>

        <version>2.5</version>

        <executions>

          <execution>

            <id>default-deploy</id>

            <phase>deploy</phase>

            <goals>

              <goal>deploy</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

      <plugin>

        <artifactId>maven-site-plugin</artifactId>

        <version>2.0.1</version>

        <executions>

          <execution>

            <id>default-site</id>

            <phase>site</phase>

            <goals>

              <goal>site</goal>

            </goals>

            <configuration>

              <outputDirectory>F:\projetos\maven.default\target\site</outputDirectory>

              <reportPlugins>

                <reportPlugin>

                  <groupId>org.apache.maven.plugins</groupId>

                  <artifactId>maven-project-info-reports-plugin</artifactId>

                </reportPlugin>

              </reportPlugins>

            </configuration>

          </execution>

          <execution>

            <id>default-deploy</id>

            <phase>site-deploy</phase>

            <goals>

              <goal>deploy</goal>

            </goals>

            <configuration>

              <outputDirectory>F:\projetos\maven.default\target\site</outputDirectory>

              <reportPlugins>

                <reportPlugin>

                  <groupId>org.apache.maven.plugins</groupId>

                  <artifactId>maven-project-info-reports-plugin</artifactId>

                </reportPlugin>

              </reportPlugins>

            </configuration>

          </execution>

        </executions>

        <configuration>

          <outputDirectory>F:\projetos\maven.default\target\site</outputDirectory>

          <reportPlugins>

            <reportPlugin>

              <groupId>org.apache.maven.plugins</groupId>

              <artifactId>maven-project-info-reports-plugin</artifactId>

            </reportPlugin>

          </reportPlugins>

        </configuration>

      </plugin>

    </plugins>

  </build>

  <reporting>

    <outputDirectory>F:\projetos\maven.default\target\site</outputDirectory>

  </reporting>

</project>

Após este trecho posso dizer que o Maven realmente é muito “habilidoso” e que é uma ferramenta construída para facilitar a nossa vida.

Aprenda como melhorar a qualidade do código usando o Sonar

noreply@blogger.com (Unknown) — Tue, 31 May 2011 04:33:00 +0000

Durante algumas pesquisas na internet sobre como melhorar a qualidade do código e gerenciar a necessidade de avaliar esta qualidade encontrei uma ferramenta muito útil para este desafio: Sonar. Mas o que é o Sonar?

Sonar e Qualidade de Código

O Sonar é uma plataforma para gerenciamento de qualidade de código. Esta ferramenta abrange 7 eixos de qualidade de código: Arquitetura e Design, duplicidade, testes unitários, complexidade, erros em potencial, regras de codificação e comentários.

Plugins

Seja através da adição de novas linguagens, mecanismos de regras, avançadas regras de computação de informações podem ser realizadas através do poderoso mecanismo de extensões. Atualmente o Sonar possui mais de 30 plugins disponíveis.

Linguagens Atendidas

A linguagem Java é a linguagem padrão porém existe plugins gratuitos e pagos para atender C, C#, Flex, Natural, PHP, PL/SQL, Cobol e Visual Basic 6.

Em 3 cliques

O Sonar possui uma forma eficiente de navegação, através de uma tela com informações organizadas em mais alto nível, um painel com informações específicas do projeto, uma espécie de maquina do tempo onde é possível visualizar a evolução(ou não) do projeto e ferramentas para busca de defeitos. Desta forma é possível detectar rapidamente os projetos e / ou componentes que estão com problemas técnicos estabelecendo planos de ação adequados.

Qualidade é o Foco

O Sonar é uma aplicação web. Regras, alertas, limites, exclusões, definições… podem ser configurados on-line. Ao manter uma base de informações sempre atualizadas, o sonar não somente permitirá a combinação de métricas completamente mas também misturá-los com medições do passado.

Minhas Considerações

Comecei a usar esta ferramenta com o interesse em verificar o quanto a mesma seria importante na melhoria da qualidade dos projetos os quais participo. O Sonar foi fundamental para a identificação de erros graves(até então encobertos), assim como identificação dos pontos de melhoria, avaliação da arquitetura, padrões de desenvolvimento de código, métricas etc.

A facilidade na implantação foi algo crucial. Em poucos minutos e pronto, está um novo projeto configurado e com análise aplicada. Mesmo em projetos que não utilizavam o Maven rapidamente fiz um pom.xml que permitisse a primeira análise.

Qual o próximo passo?

Após deixar no ar aquela vontade de ver o Sonar na prática sugiro os seguintes links:

Veja como é fácil avaliar a qualidade do código do seu projeto.

noreply@blogger.com (Unknown) — Tue, 31 May 2011 04:29:00 +0000

~~Avaliar a qualidade de um código é muito difícil~~…Não é mais! Irei explicar a forma mais fácil de avaliar como está o seu projeto sem muitas dores de cabeça.

Mas para isto o seu projeto precisa de um pom.xml. Caso o seu projeto não esteja configurado no Maven sugiro que crie um pom.xml que se adapte as suas necessidades. Vale a pena o investimento já que em poucos minutos estará executando o Sonar e avaliando a qualidade do seu projeto.

Para conhecer o Sonar leia Aprenda como melhorar a qualidade do código usando o Sonar.

Caso não conheça ainda o Maven sugiro ler Maven em 5 Minutos já que irei usar o projeto desta postagem como exemplo.

Antes de mais nada é necessário fazer o download do Sonar.

Após o download descompacte o arquivo e vá para a subpasta bin e escolha a opção mais adequada ao seu ambiente de desenvolvimento. No meu caso irei usar bin/windows-x86-64/StartSonar.bat. Após poucos minutos estará funcionando o servidor do sonar em seu computador. O endereço padrão é http://localhost:9000/. Acesse e terá uma versão um tanto quanto crua(sem alguns outros plugins interessantes do Sonar).

O que fazer agora? Usando o meu famoso projeto de exemplo usado na postagem Maven em 5 Minutos execute o comando mvn sonar:sonar. Lembre-se que a primeira vez uma quantidade enorme de bibliotecas e plugins serão baixados para o seu repositório. No meu caso nem demorou muito, veja:

Pronto, já estamos com o projeto analisado pelo Sonar. Sem muito esforço fizemos uma varredura no código do projeto, que neste caso é bem simples, e já podemos acessar novamente o endereço http://localhost:9000/.

Veja algumas telas:

Sugiro que execute este exemplo e depois aplique em seus outros projetos. Participe desta postagem deixando suas dúvidas e comentários. Assim que for possível estarei respondendo aos comentários.

Os principais recursos disponíveis no Maven

noreply@blogger.com (Jony Ferreira) — Fri, 20 May 2011 15:51:00 +0000

O Maven é uma ferramenta muito interessante porém as vezes mal compreendida. Irei apresentar de forma simplificada os principais recursos disponíveis.

A criação de um projeto é muito simples. Além disso isto é feito seguindo as melhores práticas. Comece o desenvolvimento de um novo projeto em poucos segundos.

O uso consistente em todos os projetos não significa um tempo de aprendizado muito grande para novos desenvolvedores que estão iniciando em um projeto.

Gerenciamento avançado através de atualizações automáticas e resolução de dependências(também conhecidas como dependências transitivas).

Habilidade de trabalhar com vários projetos ao mesmo tempo.

Grande quantidade de repositórios para as bibliotecas já disponíveis assim como suas atualizações com disponibilidade em tempo real.

Grande extensibilidade já que é possível facilmente criar novos plugins em Java ou até mesmo em linguagens de script.

Acesso praticamente imediato a novos recursos sem a necessidade de configuração extra.

Possibilidade de criar tarefas ant(no próprio build.xml característico do ant) com gerenciamento de dependências sem usar diretamente o Maven(pom.xml).

Modelo baseado em builds: Maven possui a habilidade de criar uma infinidade de projetos com formatos distintos(ear,jar,webstart,war,ejb etc) com distribuição

através do conceito de metadados para cada projeto sem a necessidade de criar qualquer script para a maioria dos projetos.

Criação de site com informações importantes sobre o projeto. Usando também o mesmo conceito de metadados para construção de um projeto, o Maven pode gerar um site ou um PDF com a inclusão de toda a documentação que for configurada como necessária. Um bom exemplo para isto é a necessidade de criação de relatórios sobre o estado de desenvolvimento do projeto.

Controle e Gerenciamento das distribuições de novos artefatos sem a necessidade de inúmeras configurações. O Maven se integra com o controle de versionamento do seu projeto(CVS, SVN, ClearCase etc), gerenciando e liberando novas versões do artefato para um local ou locais específicos para compartilhamento com outros projetos. Maven é capaz de publicar arquivos individuais, tais como um jar, um arquivo e suas respectivas dependências, documentação e até um pacote com distribuição do código fonte.

Gerenciamento de Dependência: Maven incentiva o uso de um repositório central de arquivos JARs assim como suas dependências. Existe um mecanismo que permite que os clientes do seu projetos possam simplesmente fazer o download dos arquivos necessários para a construção dos seus projetos. Para isto basta apenas distribuir a sua biblioteca em um repositório central. A grande vantagem é que isto permite que os usuários do Maven distribuam os seus projetos JARs e incentiva a comunicação entre os projetos para garantir que as questões de compatibilidade com versões anteriores sejam abordadas.

Como usar o log4j nos testes unitários

noreply@blogger.com (Jony Ferreira) — Fri, 20 May 2011 10:16:00 +0000

Esta é uma dica muito importante quando é necessário criar classes de testes para o seu projeto. Desta forma conseguimos

verificar no console utilizado para o próprio Maven ou até mesmo em um arquivo o prosseguimento dos testes.

O primeiro passo deste exemplo é a criação do projeto basicamente. Estou usando como exemplo o projeto em Maven em 5 Minutos.

Após criar o projeto conforme explicado no link será necessário alterar o pom.xml e criar o arquivo log4.properties.

Arquivo de configuração do Log4j

Crie um arquivo log4.properties na pasta src\test\resources e inclua o seguinte trecho de código:

log4j.logger.br.com=DEBUG, rolling1
# Console Append  
log4j.appender.rolling1=org.apache.log4j.ConsoleAppender    
log4j.appender.rolling1.layout=org.apache.log4j.PatternLayout    
log4j.appender.rolling1.layout.ConversionPattern=%d{dd/MM/yyyy HH\:mm\:ss,SSS} %-5p %c{2}.%M - %m%n

Alteração do pom.xml

Inclua a dependência do Log4j:

<dependency>
 <groupId>log4j</groupId>
 <artifactId>log4j</artifactId>
 <version>1.2.16</version>
 <type>jar</type>
</dependency>

Inclua a configuração do plugin maven-surefire-plugin para que seja possível usar o log4j nos testes unitários:

<build>
 <plugins>
  <plugin>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.8.1</version>
   <configuration>
    <systemProperties>
     <property>
      <name>maven.junit.sysproperties</name>
      <value>log4j.configuration</value>
     </property>
     <property>
      <name>log4j.configuration</name>
      <value>file:target/test-classes/log4j.properties</value>
     </property>
    </systemProperties>
    <includes>
     <include>**/*Test.java</include>
    </includes>
   </configuration>
  </plugin>
 </plugins>
</build>

O novo arquivo pom.xml deve ficar semelhante ao código abaixo após todas as alterações:

<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>br.com.maven3.tutorial</groupId>
 <artifactId>projeto.exemplo</artifactId>
 <packaging>jar</packaging>
 <version>1.0-SNAPSHOT</version>
 <name>projeto.exemplo</name>
 <url>http://maven.apache.org</url>
 <dependencies>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>3.8.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.16</version>
   <type>jar</type>
  </dependency>
 </dependencies>
 <build>
  <plugins>
   <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.8.1</version>
    <configuration>
     <systemProperties>
      <property>
       <name>maven.junit.sysproperties</name>
       <value>log4j.configuration</value>
      </property>
      <property>
       <name>log4j.configuration</name>
       <value>file:target/test-classes/log4j.properties</value>
      </property>
     </systemProperties>
     <includes>
      <include>**/*Test.java</include>
     </includes>
    </configuration>
   </plugin>
  </plugins>
 </build>
</project>

Alteração da Classe de Testes

No exemplo que acabamos de criar já foi criado também a classe AppTest em src\test\java\br\com\maven3\tutorial.

Altere a classe para o conteúdo abaixo:

package br.com.maven3.tutorial;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import org.apache.log4j.Logger;
/**
 * Unit test for simple App.
 */
public class AppTest extends TestCase {
 static Logger logger = Logger.getLogger(AppTest.class);
 /**
 * 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() {
  logger.info("return new TestSuite( AppTest.class )");
  return new TestSuite(AppTest.class);
 }
 /**
 * Rigourous Test :-)
 */
 public void testApp() {
  logger.info("assertTrue( true )");
  assertTrue(true);
 }
}

Após os procedimentos acima basta executar o comando mvn test.

Pronto, já temos um projeto com testes unitários configurado corretamente no Maven!

Maven em 5 Minutos

noreply@blogger.com (Jony Ferreira) — Tue, 17 May 2011 06:00:00 +0000

Veja como em pouco tempo já conseguimos criar um projeto no Maven!

Instalação

Maven é uma ferramenta Java, portanto, é necessário ter o Java instalado para prosseguir.

Para início de conversa, faça o download do Maven e siga as instruções de instalação. Após este passo digite o seguinte comando no terminal ou no prompt de linha de comando:

mvn –version ou também mvn –v. No meu computador, por exemplo, apareceu o seguinte resultado:

Atenção amantes do Linux, sim eu uso Windows!

Atenção, segundo o próprio site do Maven, dependendo da sua configuração de rede, você pode precisar de mais configurações extras. Em casa, por exemplo, não tenho restrições de proxy, já no trabalho, é necessário configurar informações de acesso a rede(usuário e senha para servidor proxy).

Criando um projeto

Abra uma nova linha de comando e execute o seguinte comando:

mvn archetype:generate -DgroupId=br.com.maven3.tutorial -DartifactId=projeto.exemplo -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Caso tenha acabado de instalar o Maven a primeira execução pode demorar um um pouco. Não estranhe, o Maven irá instalar as últimas atualizações dos artefatos necessários(plugins e outros arquivos) para o seu repositório local. Na prática você pode precisar executar mais de uma vez para que realmente funcione. Como disse, não estranhe a princípio. Isto pode acontecer devido ao servidor remoto que demorar muito e ocasionar os conhecidos timeouts antes do término dos downloads necessários.

No meu computador, que já possui o Maven configurado demorou apenas 7 segundos, veja:

Você perceberá que ao executar o comando será criado um diretório com o mesmo nome associado como um artifactId.

Para ficar mais fácil de apresentar esta estrutura resolvi importar o projeto que acabamos de criar no Eclipse, conforme tela abaixo:

Após selecionar a opção de importar um projeto Maven já existente(menu File/Import do Eclipse, indique a pasta onde está o seu projeto criado.

Veja que neste exemplo usamos o conceito de Templates de Projeto Maven para agilizar o processo.

O diretório src/main/java contém o código fonte do projeto. A pasta src/test/java contém o código fonte necessário para os testes. O Arquivo pom.xml define o modelo do projeto assim como as suas particularidades, ou simplesmente, POM.

O POM

O arquivo pom.xml é o núcleo da configuração do projeto no Maven. Este arquivo de configuração contém a maioria das informações necessárias para construir um projeto exatamente da forma que você precisa. O POM é algo complexo e inicialmente pode até te assustar(para ser mais sincero ainda, sempre assusta aos iniciantes!) devido ao nível de complexidade que podemos configurar nele porém não é necessário conhecer todos os detalhes para que você possa usá-lo com eficiência. No nosso exemplo o POM ficou assim:

<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>br.com.maven3.tutorial</groupId>
  <artifactId>projeto.exemplo</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>projeto.exemplo</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 pergunta óbvia…O que eu realmente preciso fazer agora?

Você executou o comando Maven archetype:generate passando vários parâmetros. O prefixo archetype é o plugin que contém a meta(ou goal no inglês). Caso esteja familiarizado com o Ant, você fazer uma analogia com algo semelhante a uma task. Este goal(ou meta, fique a vontade para usar o mais apropriado) criou um projeto simples baseado em um archetype(ou template de projeto). Por enquanto, basta dizer que um plugin é uma coleção de metas com um objetivo geral comum.

Dica: Depois leia também sobre o ciclo de vida de um projeto Maven.

Construa o Projeto

mvn package

O comando abaixo irá imprimir uma série de várias ações e no final teremos a seguinte mensagem de sucesso(claro, se você fez tudo certo):

Ao contrário do primeiro comando executado(archetype:generate) você pode perceber que é uma simples palavra package. Embora isto parece uma meta(ou goal), isto é na verdade uma fase(phase). A fase é passo do ciclo de vida de construção do projeto, ou seja, parte de uma série ordenada de fases necessários. Quando uma fase é informada, o Maven irá executar cada fase na sequência até que inclua a última informada no comando( no caso mvn package). Por exemplo, para executarmos a fase compile as seguintes fases também serão executadas antes: validate, generate-sources, process-sources, generate-resources e finalmente compile.

Para testar o arquivo jar compilado e empacotado neste exemplo apenas com o seguinte comando:

java -cp target/projeto.exemplo-1.0-SNAPSHOT.jar br.com.maven3.tutorial.App

A saída deve ser:

Hello World!

Gerando o Site

mvn site

Esta fase gera um site baseado na informação contida no pom.xml. Você pode olhar esta documentação gerada em target/site.

Finalizando…

Espero que este resumo de 5 minutos venha despertar o interesse no uso do Maven. Isto é bem simples e não tem o caráter de ser sua referência para seguir em frente. Descubra o que é possível criar via Maven e depois comente aqui os resultados. Pesquise mais neste blog sobre o assunto ou vá até as referências do próprio Maven.

Demorei um pouco mais de 5 minutos para escrever mas com certeza fará em menos de 5 minutos!

Boa Sorte.

Guia de Propriedades existentes no Maven

noreply@blogger.com (Unknown) — Sat, 23 Apr 2011 15:00:00 +0000

O maven possui uma lista de propriedades que são muito úteis na criação de um novo projeto.

Nesta postagem irei apresentar algumas destas propriedades. Espero que seja útil.

No Maven 3 todas as propriedades pom.* foram descontinuadas. Agora as propriedades iniciam com project.*

Propriedades de Build

${basedir} – representa o diretório que contem o pom.xml
${version} – é equivalente a ${project.version} ou ao antigo ${pom.version}

Propriedades Pom/Project

Todos os elementos contidos no pom.xml podem ser referenciados com o prefixo project. ou através do prefixo pom. A lista abaixo funciona com os dois prefixos, para facilitar irei apresentar apenas com project.

${project.build.directory} – representa o caminho para a pasta target. É semelhante a ${pom.project.build.directory}
${project.build.outputDirectory} – indica o caminho para onde as classes serão compiladas. O diretório padrão é "target/classes".
${project.name} ou ${pom.name} indicam o nome do projeto
${project.version} ou ${pom.version} indicam a versão do projeto
${project.build.finalName} – indica o nome final do artefato que será gerado e empacotado na pasta target.

Configurações Locais

Propriedades definidas no arquivo settings.xml local na pasta do usuário podem ser referenciadas diretamente em seu projeto através do prefixo settings.

${settings.localRepository} - é uma referencia ao repositório local definido no settings.xml

Aos que ainda não conhecem este arquivo sugiro consultar a pasta: C:\Documents and Settings\<seu_usuario_windows>\.m2\settings.xml ou no caso do Linux em ~/.m2/settings.xml.

Variáveis de Ambiente

As variáveis de ambiente podem ser referenciadas apenas usando o prefixo env

${env.M2_HOME} - informa o diretório raiz onde está instalada a versão do Maven.
${java.home} – indica o diretório da instalação do JRE_HOME. Para usar corretamente em seu projeto sugiro usar conforme o exemplo abaixo

<properties>  <jvm>${java.home}../bin/java.exe</jvm></properties>

Propriedades customizadas no projeto

No Maven existe a possibilidade de criar novas propriedades em seu projeto(conforme visto inclusive no exemplo de variáveis de ambiente acima).

Veja um exemplo:

<project>...  <properties>     <nome.ambiente>desenvolvimento</nome.ambiente>     <versao.biblioteca>1.2.3</versao.biblioteca>  </properties>...</project>

Para usar estas variáveis em seu projeto basta apenas inserir o código ${nome.ambiente} e ${versao.biblioteca}.

Propriedades herdadas de um Projeto Pai

Para usar propriedades definidas em um projeto Pai basta apenas usar o prefixo ${project.parent}.

Uma boa forma de determinar quais são as possíveis variáveis que podem ser acessadas de um projeto pai é pesquisar a api do Maven. Nesta postagem usei a versão do Maven 3.0.3. Está acessível em http://maven.apache.org/ref/3.0.3.

Super dicas para início rápido no uso do Maven

noreply@blogger.com (Jony Ferreira) — Fri, 15 Apr 2011 15:53:00 +0000

Visando facilitar você que está começando a usar o Maven compilei uma lista com algumas dicas muito úteis que irão ajudar o início desta longa e grande viagem sem volta!

1) A melhor forma de iniciar um projeto Maven é através de templates já prontos para uso.

Visite: http://maven3tutorial.blogspot.com/2011/03/dicas-para-usar-templates-de-projetos.html

2) Existe uma lista de comandos básicos no Maven. Faça alguns testes e entenda na prática como funciona cada um deles. Veja o que acontece na pasta target do seu projeto. Seguem os comandos:

mvn compile
mvn jar:jar
mvn test
mvn package
mvn install
mvn eclipse:eclipse
mvn package
mvn clean

3) Pular os testes( isto é muito importante mas... quem sabe você não precise testar no momento, não é?) mvn <comando> -Dmaven.test.skip=true

4) Crie profiles de execução:
mvn <comando> -P desenvolvimento

O exemplo abaixo explica como usar 2 tipos diferentes de profiles: tomcat e jboss:

mvn <comando> -P tomcat

mvn <comando> -P jboss

Caso seja necessário é possível executar dois profiles de uma só vez:

mvn –P profile1 –P profile2

Agora, um exemplo para criação de um projeto web com o conteúdo aberto(war:exploded):
mvn clean package war:exploded -P tomcat

Acesse o link para mais informações sobre profiles: http://maven.apache.org/guides/introduction/introduction-to-profiles.html

5) Instale qualquer arquivo no repositório local Imagine que você precise criar um arquivo jar e este será compartilhado entre seus vários projetos...
Você pode instalar qualquer jar que quiser, mesmo não sendo do projeto maven (como no exemplo abaixo):
mvn install:install-file -DgroupId=toplink -DartifactId=toplink-essentials -Dversion=2.7 -Dpackaging=jar -Dfile=toplink-essentials.jar

6)Veja como funciona os plugins disponíveis no Maven. Um bom plugin possui uma boa página de documentação.
Segue alguns que eu recomendo:
http://maven.apache.org/plugins/maven-antrun-plugin/
http://mojo.codehaus.org/build-helper-maven-plugin/
http://maven.apache.org/plugins/maven-assembly-plugin/
http://maven.apache.org/plugins/maven-eclipse-plugin/

7)Links importantes para conhecer:
http://maven.apache.org/plugins/index.html
http://maven.apache.org/run-maven/index.html
http://maven.apache.org/articles.html

O Maven é um substituto para o Ant?

noreply@blogger.com (Unknown) — Tue, 12 Apr 2011 10:03:00 +0000

Estava pensando nisso por estes dias: O Maven é um substituto para o Ant?

Por trabalhar há algum tempo com as duas ferramentas consegui identificar características as quais definem cada uma delas…mas será mesmo que podemos radicalizar assim substituindo uma por outra?

Caso você trabalhe em um projeto já consolidado e organizado com Ant há muito tempo talvez seja melhor um conhecimento aprofundado sobre o Maven para garantir que a mudança seja realmente necessária e que não irá causar impactos no seu trabalho.

Uma grande dica que sempre levo em consideração ao decidir usar uma ferramenta ou outra: DIVIDIR PARA CONQUISTAR! Pois é, identificar pequenas partes de seu projeto é um fator importante para esta decisão.

Como disse dividir para conquistar é algo muito importante no momento de estruturar um projeto, então, identifique todos os artefatos gerados(ear, war, jar, ejbs etc). Tente criar um pom.xml específico para cada módulo separado. Lembre-se que no final deve existir um projeto pai que identifique todos os módulos gerados.

Outra grande dica é: faça o Maven coexistir com o Ant pelo menos no início. Tente fazer via Maven o que é realizado com Ant. Caso encontre problemas no uso do Maven, a geração dos artefatos está garantida no Ant.

Quando comecei no uso do Maven ainda usei muito o Ant para tarefas as quais ainda não sabia usar via Maven. Usei alguns plugins para isto e em momentos também mantive o famoso build.xml do Ant também.

Mas e a pergunta titulo desta postagem? Alguém pode responder através dos comentários? Bom, vou deixar a minha conclusão aqui, espero comentários.

O Maven pode substituir o Ant em muitos momentos porém creio que o Ant é tão importante quanto o Maven nos projetos. Ao implantar o Sonar nos projetos os quais eu participo esbarrei em uma grande dificuldade: O Sonar funciona muito bem com o Maven mas como vou executar todos os 20 e tantos projetos que estão agora usando esta ferramenta para análise e qualidade de código? Na mão? Executando um a um? Nunca! Aprendi com um grande professor, na época da faculdade de engenharia, que assim como a Física, a Matemática, enfim, o conhecimento adquirido, a Informática também é uma ferramenta muito útil na nossa vida diária. Pois é, lembrei disso, o que fiz para resolver o problema de execução da qualidade de código dos projetos? Usei o Ant para isto. Alguns podem perguntar, porque não usa o Hudson? Pois é, eu usei porém imagine configurar isto para 20 e poucos projetos? Resolvi então criar um script no Ant que exatamente identifica todos os pom.xml existentes em nossa estrutura de projetos e executa o comando maven para executar a qualidade de código via Sonar de uma só vez…Ficou mais simples porém o resultado foi alcançado conforme esperado.

Lembre-se sempre: tarefas repetitivas significam perda de tempo, automatize tudo o que for necessário. Não podemos perder tempo com tarefas comuns que poderiam estar claramente organizadas em um procedimento automático. Pense no Ant e no Maven para tais tarefas. Descubra qual é mais adequado para cada uma delas.

De volta a conclusão…

Resumindo, o Maven e Ant são ferramentas complementares e possuem um grande valor devido as suas particularidades. Não seja um extremista dizendo que uma é melhor do que a outra e ponto. Aprenda na prática que o bom uso de cada uma delas irá trazer benefícios distintos e que no final irão trazer um beneficio ainda maior ainda para todos aqueles que participam no projeto junto com você. Não quero em nenhum momento formar opinião. Prefiro que tomem suas próprias decisões sobre o que é melhor, como proceder etc. Caso existam dúvidas posso até ajudá-lo como prosseguir.

Comentem as suas dúvidas, sugestões, reclamações…Defendam suas ideias nos comentários.

Dicas para usar templates de projetos pré-configurados no Maven - Maven Archetypes

noreply@blogger.com (Jony Ferreira) — Wed, 30 Mar 2011 01:10:00 +0000

Sempre quando iniciamos um novo projeto precisamos passar pelos mesmos pontos, definindo características e configurações as quais serão responsáveis pelo ciclo de vida de criação do projeto.
Por que não reaproveitar isto? Pois é, isto é possível através do uso de Templates de Projeto,
conhecidos como Maven Archetypes.

Praticamente existe um template para cada tipo específico de projeto:

Para ver a lista de possíveis templates já existentes execute o comando:

mvn archetype:generate

Veja que no final é possível selecionar um template como exemplo para prosseguir.

Existe uma lista enorme de possíveis templates porém vou falar rapidamente apenas de alguns dos principais:

maven-archetype-j2ee-simple- Template para um projeto J2EE simples.
maven-archetype-portlet -Template que contém exemplo para JSR-268 Portlet.
maven-archetype-quickstart - Um template que contém um exemplo de um projeto maven.
maven-archetype-simple - Um template para um projeto simples.
maven-archetype-site - Um template que contém um exeplo de um Maven site o qual demonstra alguns dos documentos suportados, tais como APT, XDoc, and FML e demonstra como usar internacionalização em seu site.
maven-archetype-webapp - Exemplo para criação de um projeto web.

Caso não queira selecionar de uma lista você pode simplesmente executar a geração do projeto informando um template específico:

mvn archetype:create -DgroupId=br.com.projeto.exemplo -DartifactId=projeto-web -DarchetypeArtifactId=maven-archetype-webapp

Ao executar esta linha acima o maven irá criar um projeto chamado projeto-web baseado no template maven-archetype-webapp.

Este template cria a seguinte estrutura:

projeto-web
pom.xml
projeto-web/src/main/resources
projeto-web/src/main/webapp/index.jsp
projeto-web/src/main/webapp/WEB-INF\web.xml

Fácil não? Sugiro que teste outros templates e veja como funciona!

Para maiores informações visite os links:
http://maven.apache.org/guides/introduction/introduction-to-archetypes.html
http://maven.apache.org/archetype/maven-archetype-plugin/usage.html

Por que decidi usar o Maven em meus projetos?

noreply@blogger.com (Unknown) — Sun, 27 Mar 2011 19:08:00 +0000

Ouvi falar do Maven pela primeira vez em 2002. Nesta época um Consultor da Accenture, Marcio, falou comigo mais ou menos assim: “Big Head”, estude Maven pois é o futuro!

Na época achei engraçado a forma o qual falou pelo seguinte motivo: ele nunca tinha feito alguma coisa com a ferramenta porém tinha entendido o conceito aplicado através dela.

Meses depois eu estava “tentando estudar” o Maven. Confesso que desisti logo, era um pouco difícil para mim entender na prática algo que conceitualmente não tinha vivenciado e entendido como aplicar com sucesso nos projetos os quais eu participei. Nesta época, por trabalhar em uma fábrica de software aplicar tais conceitos não eram fáceis. Logo então parei de estudar o Maven.

Alguns anos depois resolvi então vencer a barreira e tentar entender. Já trabalhava com Ant porém ainda tinha certa antipatia com o tal do Maven. Descobri que esta antipatia ocorreu por falta de conhecimento necessário para aplicá-los em um projeto real.

Após alguns dias estudando comecei a ver o Maven na prática funcionado. Quando você entende um pouco do Maven a primeira coisa que passa em sua mente é migrar todos os outros projetos que você possui para o Maven.

Abrindo parênteses:

Caso seja um projeto criado através do Eclipse, e sem ant, sugiro no futuro migrá-lo para maven, não é muito difícil, em breve estarei explicando como fazer isto.

Voltando ao assunto…

Como diz um grande amigo meu, Dirceu, na prática a teoria é outra! Pois é, nem sempre sem maturidade prática no uso do Maven é possível mudar tais projetos.

Automatização do Projeto

Quando consegui realmente aplicar o Maven, ou seja, dominar o que eu estava configurando através da ferramenta, consegui identificar uma grande vantagem: automatização. Atingi um nível considerável de automação do projeto com pouca configuração. Quando trabalhamos com várias versões de sistemas ou bibliotecas é um pouco chato ficar criando pacotes via Eclipse. Nada contra o Eclipse. Eclipse é muito bom para o que ele tem de principal: edição de código. Para criação de pacotes para releases por exemplo nada melhor do que uma formalização escrita do que realmente é necessário fazer para compilar, gerar os pacotes e instalar uma aplicação.

Qualidade

O maven é um incentivador para criação de testes unitários. Isto mesmo, nada é mais fácil do que ter testes unitários organizados e que valide toda a sua aplicação para evitar possíveis bugs e até mesmo que pacotes sejam distribuídos com problemas. Achei interessante que através de testes unitários através no Maven posso garantir que novos pacotes sejam criados apenas se os testes forem validados com sucesso. Isto é configurável porém é algo muito interessante.

Falando em qualidade, veio a minha mente, qualidade de código. O Maven é integrado a uma ferramenta conhecida como Sonar, esta ferramenta é o que faltava no Maven para validação de qualidade de código porém de uma forma mais apresentável. O Maven por si só já cria relatórios estáticos sobre qualidade de código. Através do Sonar estes testes passaram para um novo patamar de avaliação do que pode ser melhorado em um sistema.

Vale a pena conferir em http://www.sonarsource.org/

Para ver os resultados gerados via Sonar visite a página http://nemo.sonarsource.org/

Plugins

O Maven trabalha com o conceito de plugins, existem centenas(por que não milhares) de plugins disponíveis para uso. Como descobri tais plugins? Pesquisando no Google mesmo! Hoje quem não usa destes artifícios está perdido no meio de tantas informações. Quem sabe você achou este blog assim também!

Sugestão: antes de pensar em construir o seu próprio plugin pense em procurar algo que já faça o que você precisa. Não reinvente a roda. Estamos falando de projetos que na maioria das vezes possui um prazo para entrega!

Através do uso de plugins, já que tudo no Maven funciona como plugin, é possível baixar um código de um servidor remoto, compilar, aplicar testes unitários, gerar relatórios para qualidade de código, empacotar, validar o pacote gerado, versioná-lo em um determinado sistema de controle de versionamento e finalmente instalá-lo. Isto é tudo praticamente que precisamos controlar no ciclo de vida de construção de um projeto.

Para entender melhor como funciona o ciclo de vida do projeto visite o link.

Organização

Uma outra grande vantagem é o conceito de cascateamento de configurações através da estrutura de hierarquias de POM. Desta forma não é necessário duplicar configurações comuns entre projetos já que é possível definir que um projeto possui um projeto pai o qual ele herda todas as configurações. Que bom é ser filho! Mas lembre-se um dia você também será pai!

Estrutura Modular

A organização de projetos de forma modular é algo que facilita muito já que podemos criar um projeto dividido em seus respectivos módulos. Imagine juntar tudo isto sem organização, é como arrumar um guarda-roupas todo bagunçado sem saber por onde começar!

Afinal, quem toma conta dos filhos? Claro, os pais! No maven é parecido. Através da definição de um projeto pai,que possui projetos filhos ou módulos, iremos controlar todo o ciclo de construção dos projetos filhos. Pensando bem não é um projeto pai, é um projeto chefe, não? Tudo que é pedido para que seja realizado pelo projeto chefe os seus subordinados acabam fazendo também! Esta é uma explicação mais adequada sobre build modular!

Através desta organização, claro, seguindo as configurações comuns do Maven, o resultado será uma geração de pacotes simples, eficiente e rápida!

IDE para desenvolvimento

O Maven é independente de IDE para desenvolvimento(Eclipse, NetBeans etc.). Atualmente trabalho com o Eclipse e o NetBeans e através do Maven vivo abrindo o projeto nas duas plataformas. Claro, não sou louco, faço isto pois possuo projetos que são desenvolvidos em Java para Desktop e estes são muito mais fáceis para criá-los no NetBeans.

Mas de vez em quando, quando bate saudade, vou para a linha de comando e executo meus projetos por lá! Não ria, não é engraçado, também funciona assim. Apenas gosto de liberdade de escolha.

Conclusão

Poderia aqui explicar um monte de coisas sobre o Maven porém a melhor forma de aprendizado é prática de alguns conceitos explicados brevemente neste blog.

Sugiro que procure por exemplos de projetos na internet antes de começar a criar o seu próprio no Maven. Aprendi muita coisa exatamente vendo e entendo como os outros projetos funcionavam com Maven. Ah uma outra dica: procure por documentação e exemplos dos plugins. Um bom plugin possui um bom site de documentação e exemplos.

O tempo que você gasta reclamando da geração manual de pacotes porque não gasta o mesmo tempo mais um pouco aprendendo como usar esta ferramenta e veja você mesmo as vantagens.

Espero ter ajudado em alguma coisa. Este post possui alguns pontos pessoais e nem sempre irei agradar a todos os leitores.

Espero também por contribuições e comentários para que possamos melhorar ainda mais o blog.

O que o Maven faz que não posso fazer no Ant?

noreply@blogger.com (Unknown) — Sun, 27 Mar 2011 18:55:00 +0000

Esta é uma pergunta de muitos, os que não conhecem o Maven por Exemplo, quem sabe talvez os conservadores também?

O Maven não faz nada além do que você mesmo possa fazer através do Ant.

A diferença é que o Maven fica responsável por tarefas que você tem que criar através do Ant. Na prática por exemplo, sabemos que para criar testes unitários via ant é necessário um certo esforço. No Maven isto já está nativamente disponível em seu projeto apenas executando o comando mvn test. Ele automaticamente compila o código necessário e cria o ambiente de testes unitário conforme as classes de Testes previamente definidas e finalmente testa as classes. Simples não? Imagine fazer isto na mão?

O maven também possui centenas( já disse antes: por que não milhares?) de plugins ou wizards prontos para o seu uso. A quantidade de plugins do maven é superior(e muito) a quantidade de Ant Tasks disponíveis.

No Ant por exemplo, se é crida uma nova Ant Task e você quer usá-la é necessário fazer o download dos pacotes necessários e configurar no build.xml. Esta prática no Maven pode ser automática, sem a necessidade de ficar verificando uma nova versão, downloads e configurações. Isto é automático.

Os pontos aqui informados não são pessoais. Eu uso o Ant também e ele é muito bom no que se propõe a fazer porém em alguns momentos é melhor verificar o que o Maven pode agregar em cada caso.

Por favor contribua com mais diferenças entre Maven e Ant nesta postagem!

Ciclo de Vida de Construção de um projeto Maven

noreply@blogger.com (Jony Ferreira) — Mon, 07 Mar 2011 14:42:00 +0000

Maven é baseado no conceito de ciclo de vida de projeto. Isto significa dizer que o processo para construção de um determinado artefato é claramente definido.

Para a construção de um projeto específico é necessário aprender uma lista de comandos e o Maven, através das definições do POM, será responsável por gerar os artefatos conforme desejado.

Existem 3 tipos de ciclo de vida de construção do projeto: default, clean e site. O default trabalha com o a construção dos artefatos desde a criação até a instalação. O clean é responsável pela limpeza de todos os arquivos gerados no ciclo default. O ciclo site é responsável pela criação da documentação do projeto.

O Ciclo de Vida do Projeto é divido em fases

Cada um dos ciclos acima explicados são definidos por um grupo diferente de fases, onde cada fase representa um estágio no ciclo de vida do projeto.

Por exemplo, o ciclo default possui as seguintes fases:

validate - valida se o projeto está correto e se todas as informações necessárias estão disponíveis
compile - compila o código fonte do projeto
test - testa o código compilado usando uma framework de testes. Estes testes não necessitam do código fonte.
package - reúne o código compilado e empacota em algum formato especificado, por exemplo, um jar ou um war.
integration-test - integration-test - processa e instala o pacote caso seja necessário em um ambiente onde os testes serão executados.
verify - executa algumas verificações para identificar se o pacote é válido e se atende os critérios de qualidade
install - instala o pacote em um repositório local, para ser usado como uma dependência em outros projetos locais.
deploy - realizado em um ambiente de integração ou distribuição, copia o pacote para um repositório remoto para compartilhamento com outros desenvolvedores ou projetos.

Estas fases de construção(levando em consideração que existem outras fases ainda não mencionadas) são executadas de forma seqüencial até completar todo o ciclo de vida default. Isto significa que o Maven irá primeiro validar o projeto, após irá compilar os códigos-fonte, executar os testes, empacotar os arquivos binários(caso seja um jar), executar os testes de integração, verificar o pacote, instalar o pacote verificado para o repositório local e distribuir o pacote instalado em um ambiente específico.

Para executar todos os passos acima é necessário apenas solicitar a execução da última fase especificada, ou seja, deploy: mvn deploy.

Caso execute o comando mvn install as seguintes fases serão executadas, validate, compile, package etc.

Também existem casos onde é necessário executar mais de um comando para vários módulos( um bom exemplo é um projeto com sub-projetos). Por exemplo, podemos executar mvn clean install. Este comando irá verificar todos os sub-projetos e executar os comandos clean e depois install(incluindo todos os passos necessários).

Uma fase de construção é composta de metas

Embora que uma fase de construção seja responsável por um passo específico no ciclo de vida do projeto, a maneira a qual trata suas responsabilidades podem variar. Esta execução é feita através da declaração de metas para cada fase.

Uma meta(goal) representa uma tarefa específica(entre várias tarefas existentes na fase) a qual contribue para a construção e gerenciamento do projeto. Estas fases podem estar ligadas nenhuma ou muitas fases de construção. Uma tarefa que não está associada a nenhuma fase pode ser executada fora do ciclo de vida apenas por sua invocação direta. A ordem de execução depende da ordem a qual a tarefa(s) e as fase(s) de construção serão invocadas. Por exemplo, considere o exemplo abaixo. Os argumentos clean e package são fases de construção enquanto dependency:copy-dependencies é uma meta(ou tarefa).

mvn clean dependency:copy-dependencies package

Caso este comando for executado, a fase clean será executada primeiro(executando todas as tarefas precedentes ao ciclo clean do projeto até a própria fase clean), e depois, a meta dependency:copy-dependencies e, finalmente, executando a fase package(representando todas as fases precedentes ao ciclo default do projeto).

Alem disso, se uma meta está associada a nenhuma ou várias fases, a meta será invocada em todas as fases.

A fase de construção pode ter nenhuma ou algumas metas para completá-la. Caso uma fase não possua tarefas para ser executada a fase não será executada. Caso existam uma ou mais tarefas a serem completadas, todas as tarefas serão executadas.

Aprenda como criar um arquivo jar cliente para acessar um WebServices usando Maven e Axis

noreply@blogger.com (Unknown) — Fri, 04 Mar 2011 04:38:00 +0000

Com Maven é possível gerar um pacote jar cliente todas as vezes quando o wsdl que define o WebServices é modificado.

Sabemos que isto é possível criar as classes diretamente pelo Eclipse porém... imagine se amanhã você não possa mais usar o Eclipse..."Agora tenho que usar o NetBeans!... E agora?". Calma! Estamos falando de Maven...Maven funciona pela linha de comando, funciona no Eclipse e também funciona no NetBeans. Ainda que sejam formas diferentes o resultado será sempre o mesmo.

Pesquisando sobre o assunto encontrei um plugin bastante interessante: axistools-maven-plugin. Visite o site http://mojo.codehaus.org/axistools-maven-plugin/index.html para maiores informações sobre como usar este plugin.

Para exemplificar esta possibilidade eu irei apresentar um pom.xml configurado para gerar um pacote jar usando o Amazon WebService.

O primeiro passo é baixar o wsdl em http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl.

Salve este arquivo na pasta src/main/resources/wsdl.

O próximo passo é criar o arquivo pom.xml 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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.maven3.tutorial</groupId>
<artifactId>amazon.ws.client</artifactId>
<version>1.0</version>
<name>Amazon WebServices Client</name>
<description></description>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>axistools-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>generate-project</id>
<goals>
<goal>wsdl2java</goal>
</goals>
<configuration>
<!--http://soap.amazon.com/schemas2/AmazonWebServices.wsdl -->
<sourceDirectory>src/main/resources/wsdl</sourceDirectory>
<outputDirectory>target/generated-sources</outputDirectory>
<packageSpace>org.maven3.tutorial</packageSpace>
<subPackageByFileName>true</subPackageByFileName>
<serverSide>true</serverSide>
<testCases>true</testCases>
<wrapArrays>true</wrapArrays>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4</version>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>axis</groupId>
<artifactId>axis</artifactId>
<version>1.3</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
</dependency>
</dependencies>
</project>

Agora é a parte mais fácil, execute o comando mvn package para gerar o código fonte necessário para acessar o Amazon WebService.

Learn how to create a WebService Client using Maven and Axis

noreply@blogger.com (Unknown) — Fri, 04 Mar 2011 04:30:00 +0000

With Maven you can generate the client every time when the WSDL that defines theWeb services is modified.

We know that this is possible directly through Eclipse but ... Imagine if tomorrow youcan no longer use Eclipse ... "Now I have to use NetBeans ... And now?". Easy! We're talking about Maven... Maven works from the command line, it works in Eclipse and also works in NetBeans. Although they are different ways the result is always the same.
Researching the topic I found a very interesting plugin: maven-plugin-axistools. Visit http://mojo.codehaus.org/axistools-maven-plugin/index.html for more information about using this plugin.
To illustrate this possibility I will present a pom.xml configured to generate a client jar using the Amazon Web Service.
The first step is to download the wsdl in http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl.
Save this file in the folder src/main/resources/wsdl.

The next step is to create the pom.xml file below:

<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.maven3.tutorial</groupId>
<artifactId>amazon.ws.client</artifactId>
<version>1.0</version>
<name>Amazon WebServices Client</name>
<description></description>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>axistools-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>generate-project</id>
<goals>
<goal>wsdl2java</goal>
</goals>
<configuration>
<!--http://soap.amazon.com/schemas2/AmazonWebServices.wsdl -->
<sourceDirectory>src/main/resources/wsdl</sourceDirectory>
<outputDirectory>target/generated-sources</outputDirectory>
<packageSpace>org.maven3.tutorial</packageSpace>
<subPackageByFileName>true</subPackageByFileName>
<serverSide>true</serverSide>
<testCases>true</testCases>
<wrapArrays>true</wrapArrays>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4</version>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>axis</groupId>
<artifactId>axis</artifactId>
<version>1.3</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
</dependency>
</dependencies>
</project>

Now is the easy part, run the command mvn package to generate the source code needed to access the Amazon Web Service.

Criando meu primeiro projeto no Maven

noreply@blogger.com (Unknown) — Mon, 28 Feb 2011 10:27:00 +0000

Para a criação de um projeto é necessário definir seu arquivo de configuração, conhecido como POM. Neste arquivo encontram-se todas as informações sobre o projeto o qual o Maven fará a sua gerência. Seguindo os padrões, este arquivo deve estar na pasta raiz do projeto e se chamar “pom.xml”(Veremos mais a frente que isto não é necessário quando temos um projeto que não foi construído na estrutura padrão do Maven)..

Abaixo segue o POM de exemplo:

<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.maven3.tutorial</groupId>
<artifactId>first.project</artifactId>
<name>Maven 3 Tutorial</name>
<version>1.0</version>
<packaging>jar</packaging>
<description>simple description here</description>
</project>

A tag inicial da configuração é o <project />, ela contém todas as informações do projeto, nesta tag também temos a definição da versão utilizada assim como as regras das tags que podem ser utilizadas dentro deste xml.

A próxima tag é a <modelVersion/>. Esta define a versão do arquivo de configuração do Maven. No caso do Maven 3 ainda é utilizado a versão 4.0.0. Esta tag é obrigatória para que a ferramenta identifique qual a estrutura do documento.

A tag seguinte é a <groupId/>, indica o grupo de projetos onde este projeto estará associado. É uma forma de organizar mais simples vários projetos dentro de uma mesma empresa e/ou grupo de desenvolvedores. Quando você trabalha com várias aplicações, cada uma com vários módulos é muito importante definir grupos para facilitar a organização e identificação de cada parte dentro do contexto geral do seu trabalho.

A próxima tag é a <artifactId/>, esta define o projeto atual. Podemos dizer que é como um módulo dentro de uma aplicação.

A tag <name/> como seu próprio nome diz indica o nome amigável do seu projeto. No nosso caso foi utilizado Maven 3 Tutorial.

A tag <version/> indica qual versão está sendo criado. Esta tag é muito útil quando lançamos uma nova versão e queremos garantir que todos que utilizam versões anteriores não sejam impactados pelas mudanças aplicadas. Apenas se atualizarem a versão é que terão acesso as mudanças.

A tag <packaging/> define o tipo de artefato a ser gerado. No nosso exemplo foi definido que o pacote a ser gerado será do tipo jar. Quando também não definimos esta tag é assumido que será usada a tag jar(padrão). Os tipos de projetos atuais que podem ser definidos na tag <packaging/> são pom, jar, maven-plugin, ejb, war, ear, rar e par. Estas opções definem uma lista de tarefas que serão executadas conforme cada estágio de ciclo de vida do projeto conforme as suas características particulares.

Terminando, a tag <description/> é uma breve descrição que define as características principais do projeto a ser construído.

Basicamente estas tags são as principais que encontramos em todos os projetos.

O que é Maven?

noreply@blogger.com (Unknown) — Thu, 10 Feb 2011 00:27:00 +0000

Apache Maven, ou simplesmente Maven, é uma ferramenta para gerenciamento e automação de projetos em Java. Ela é similar à ferramenta Ant, mas possui um modelo de configuração mais simples, baseado no formato XML. Maven é um projeto da Apache Software Foundation.

Maven utiliza uma construção conhecida como Project Object Model (POM). Ela descreve todo o processo de construção de um projeto de software, suas dependências em outros módulos e componentes e a sua sequência de construção. O Maven contém tarefas pré-definidas que realizam funções bem conhecidas como compilação e empacotamento de código. Neste arquivo também encontramos as definições das características do projeto desde as informações básicas tais como nome, desenvolvedores, repositórios de código fonte(versionamento de código fonte, como CVS e Subversion), dependências de bibliotecas externas e até alguns outros plugins que ajudam no desenvolvimento, testes e até implantação do artefato gerado.

Uma grande característica do Maven é que ele é construído para trabalhar em rede. O núcleo da ferramenta pode baixar plugins de um repositório. (o mesmo repositório utilizado pelos outros projetos Java do Apache e outras organizações(ex>: JBoss). O Maven disponibiliza suporte nativo para a recuperação de arquivos deste repositório, e para a inclusão dos artefatos resultantes no final do processo. Um cache de artefatos atua como ponto de sincronização dos artefatos de um projeto local.

Um bom exemplo para o Maven é a possibilidade de instalar um código fonte de exemplo diretamente de um servidor, fazer o download de todas as bibliotecas necessárias, compilar todos os códigos-fonte, testar alguns métodos necessários, aplicar validações de qualidade de código, baixar um servidor web, instalar a aplicação neste servidor, inicia-lo e já estaremos acessando a aplicação de exemplo. Como isto é possível? A resposta é simples: Maven. Em breve estarei ensinando como fazer isto.

Mesmo sabendo sobre os pontos mencionados acima, o Maven ainda tem muito mais a oferecer. Esta ferramenta prega a padronização dos projetos. As configurações dos projetos são semelhantes já que sempre estarão organizados em uma estrutura semelhante. Seguir padrões é algo muito importante e o Maven sabe disso.

Visite o link http://maven.apache.org/ para maiores informações sobre esta ferramenta.

A origem do Maven

noreply@blogger.com (Unknown) — Wed, 09 Feb 2011 23:28:00 +0000

O Maven surgiu com o objetivo de simplificar os build files do Ant utilizados nos projetos desenvolvidos pela equipe do projeto Jakarta Turbine.

Eles procuravam uma maneira de deixar os seus projetos organizados em uma mesma estrutura padronizada e também não queriam mais perder tempo no envio de bibliotecas para os sistemas de controle de versão. Neste momento surgiu a primeira versão da ferramenta. Em 2005 ela foi completamente reescrita, surgindo o Maven 2, o resultado sobre toda a experiência dos desenvolvedores e usuários da primeira versão. Em Janeiro de 2011 foi liberada a versão 3.0.2. O Maven também evolui, isto que veremos nos próximos tópicos.