Processo de build com o Maven | Alura
A idéia é bem parecida com o build.xml do Ant: você deixa o pom.xml na raiz do seu projeto para poder chamar as targets de build do seu projeto. O menor arquivo pom.xml válido é o seguinte: <project> <modelVersion>4.0.0</modelVersion> <groupId>br.com.caelum</groupId> <artifactId>teste</artifactId> <version>1.0</version> </project>
Essas informações são usadas em muitos lugares, como o controle de dependências que é, na minha opinião, a funcionalidade mais útil do Maven. Por exemplo, para dizer que o log4j 1.2.15 é uma dependência da sua aplicação é só acrescentar no seu pom as linhas: <project> ... <dependencies> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.15</version> </dependency> </dependencies> ... </project> Quando necessário, o Maven vai baixar pra você o jar do log4j 1.2.15, e todas as suas dependências, e vai colocá-las no classpath da sua aplicação durante os builds, testes, etc. Ou seja, você não precisa mais entrar no site do log4j, baixar um zip com vários jars e ter que procurar quais jars devem ser colocados no classpath!
test - executa os testes unitários do código compilado, usando uma ferramenta de testes unitários, como o junit.
package - empacota o código compilado de acordo com o empacotamento escolhido, por exemplo, em JAR.
integration-test - processa e faz o deploy do pacote em um ambiente onde os testes de integração podem ser rodados.
install - instala o pacote no repositório local, para ser usado como dependência de outros projetos locais
deploy - feito em ambiente de integração ou de release, copia o pacote final para um repositório remoto para ser compartilhado entre desenvolvedores e projetos