O documento discute como o Maven pode padronizar projetos de software, tornando o build e gerenciamento dos mesmos mais simples. Ele apresenta os problemas que surgem quando projetos não possuem padrões e estrutura definida, e como o Maven resolve esses problemas através da padronização de diretórios, dependências e plugins.
3. Qual o problema?
Fazer o build dos projetos deve ser
simples, você não deve passar horas
tentando gerar um artefato a partir do
código fonte.
4. Jorge Thiago
Trabalham em partes diferentes
de um mesmo projeto
5. • Usa o NetBeans 5.0
• Monta os seus builds com Jorge
o Ant
• Usa a estrutura de
diretórios comum do
NetBeans
• Não usa um sistema de
controle de versão
6. • Usa o Eclipse 3.1 com o
Web Tools Platform (WTP) Thiago
• Faz os builds dentro do
Eclipse, com o WTP
• Usa a estrutura de diretórios
do WTP
• Também não usa um
sistema de controle de
versão
7. Um belo dia...
... Jorge fica doente
E surge um bug no seu
projeto que precisa ser
resolvido
9. Problemas?
• Thiago nunca usou o NetBeans
• Thiago nem imagina como é que se usa o
Ant
• Não é possível importar o projeto de Jorge
para o Eclipse, os diretórios não batem
11. Qual a moral da história?
Os projetos devem ser
padronizados!
12. Assuntos
• Como surgiu o Maven?
• O que é o Maven?
• Como o Maven funciona?
• Padronizando os projetos
• Maven e os seus plugins
13. Como surgiu o Maven?
• Necessidade de padronização dos sub-
projetos dentro do projeto Jakarta Turbine
• Era necessário evitar o envio de
arquivos .jar para o controle de versão
• Era necessário facilitar o entendimento de
cada sub-projeto no sistema
14. O que é o Maven?
• Gerenciador de builds
• Gerenciador de dependências
• Gerador de documentação
• Provedor de ferramentas para a avaliação
da qualidade do projeto
15. Objetivos do Maven (1-2)
• Tornar o processo de desenvolvimento visível e
transparente
• Prover uma maneira simples de analisar o status
de um projeto
• Diminuir o tempo de adequação de novos
desenvolvedores
• Reunir ferramentas necessárias uniformemente
16. Objetivos do Maven (2-2)
• Evitar configurações inconsistentes
• Prover uma estrutura comum para todos
os projetos
• Foco no desenvolvimento das aplicações,
não no build dos projetos
17. Como o Maven funciona?
• Os projetos são descritos usando o
Project Object Model (POM)
• Os plugins são invocados e executados
sobre o projeto em questão através das
informações do POM
18. O que fica no POM?
• Desenvolvedores
• Dependências
• Configuração de plugins
• Controle de versão
• Repositórios...
20. Padronizando o projeto
• O Maven define uma estrutura de
diretórios default
• A estrutura padrão é resultado da
experiência dos próprios desenvolvedores
do Maven
• É possível (mas não é aconselhável)
configurar uma estrutura de diretórios
diferente
21. Estrutura de diretórios
• src/ -- pasta raiz
– main/ -- tronco principal
• java/ -- código fonte Java
• resources/ -- recursos (arquivos de configuração, imagens, etc)
• webapp/ -- aplicação web Java
– test/ -- tronco de testes unitários e de integração
• java/ -- código fonte dos testes do JUnit
• resources/ -- recursos dos testes
• cactus/ -- códigos dos testes de integração do Cactus
– site/ -- tronco principal da documentação
22. Fases de um projeto no Maven
Gerar código inicial Empacotar
Compilar Testes de integração
Testes unitários Instalar
Implantar
23. Repositórios
• Locais de armazenamento de diversos
tipos de artefatos
• Toda a gerencia do repositório é feita pelo
próprio Maven
• Não é necessário declarar caminhos
relativos para os artefatos
25. Dependências ou artefatos
• São mantidas nos repositórios (locais ou
remotos)
• São transitivas
• Podem ser atualizadas automaticamente
pelo Maven
26. Transitividade das dependências
Dependência
• Não é necessário declarar declarada
toda a árvore de
dependências, o Maven só A
precisa saber a
dependência raiz B C
D
27. Documentação e relatórios
• Gera um site descritivo do projeto (listas
de discussão, desenvolvedores,
dependências)
• Gera relatórios sobre o projeto (qualidade,
JavaDoc, arquivos fonte)
28. O Maven e seus Plugins
• Meios de extensão para o Maven
• São buscados nos repositórios disponíveis
• São configurados dentro do POM
• Existem mais de 80 plugins oficiais
catalogados
29. Configuração de um plugin
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
30. Avaliando a migração para o
Maven 2.0
• Quando não existe padronização
• Quando o padrão é o Ant
• Quando o padrão é o Maven 1.0
31. Sem padrão
• Define um padrão para todos os projetos
• Facilita a integração e o reconhecimento
do código
• Centraliza as informações sobre projetos
e sub-projetos
32. Ant como padrão
• Diminui a quantidade de configuração
necessária para o build
• Tasks do Ant podem ser invocados pelo
Maven
• Quantidade imensa de plugins prontos
para ser utilizados
33. Maven 1.0 como padrão
• O desenvolvimento do Maven 1.0 está
congelado
• Novos plugins e integração com outras
ferramentas está sendo feito com base no
Maven 2
34. Conclusão
O objetivo principal do Maven como ferramenta
é padronizar os projetos, para que eles possam
ser gerenciados e entendidos com mais
facilidade, para que os envolvidos se
preocupem mais com o desenvolvimento e
menos com as configurações
36. Referências
• MASSOL, Vincent; O BRIEN, Timothy.
Maven: A Developer s Notebook.
O Reilly, 2005.
• MASSOL, Vincent. Maven 2.0 – Improve
your build patterns. Palestra no Javapolis
2005 – disponível em http://javapolis.com/