Maven é uma estrutura, Ant é uma caixa de ferramentas
O Maven é um carro pré-fabricado, enquanto o Ant é um conjunto de peças. Com o Ant, você precisa montar seu próprio carro, mas pelo menos se precisar dirigir fora de estrada, pode construir o tipo certo de carro.
Em outras palavras, o Maven é uma estrutura, enquanto o Ant é uma caixa de ferramentas. Se você estiver satisfeito com o trabalho dentro dos limites da estrutura, o Maven se sairá bem. O problema para mim era que eu continuava esbarrando nos limites da estrutura e isso não me deixava sair.
Verbosidade XML
tobrien é um cara que sabe muito sobre Maven e acho que ele forneceu uma comparação muito boa e honesta dos dois produtos. Ele comparou um simples pom.xml do Maven com um arquivo simples de compilação do Ant e mencionou como os projetos do Maven podem se tornar mais complexos. Eu acho que vale a pena dar uma olhada em uma comparação de alguns arquivos que você provavelmente verá em um projeto simples do mundo real. Os arquivos abaixo representam um único módulo em uma compilação de vários módulos.
Primeiro, o arquivo Maven:
<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-4_0_0.xsd">
<parent>
<groupId>com.mycompany</groupId>
<artifactId>app-parent</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>persist</artifactId>
<name>Persistence Layer</name>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>common</artifactId>
<scope>compile</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>domain</artifactId>
<scope>provided</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>${commons-lang.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.2.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>${commons-dbcp.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>${oracle-jdbc.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<version>${easymock.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
E o arquivo Ant equivalente:
<project name="persist" >
<import file="../build/common-build.xml" />
<path id="compile.classpath.main">
<pathelement location="${common.jar}" />
<pathelement location="${domain.jar}" />
<pathelement location="${hibernate.jar}" />
<pathelement location="${commons-lang.jar}" />
<pathelement location="${spring.jar}" />
</path>
<path id="compile.classpath.test">
<pathelement location="${classes.dir.main}" />
<pathelement location="${testng.jar}" />
<pathelement location="${dbunit.jar}" />
<pathelement location="${easymock.jar}" />
<pathelement location="${commons-dbcp.jar}" />
<pathelement location="${oracle-jdbc.jar}" />
<path refid="compile.classpath.main" />
</path>
<path id="runtime.classpath.test">
<pathelement location="${classes.dir.test}" />
<path refid="compile.classpath.test" />
</path>
</project>
tobrien usou seu exemplo para mostrar que o Maven possui convenções internas, mas isso não significa necessariamente que você acaba escrevendo menos XML. Eu achei o oposto verdadeiro. O pom.xml é três vezes mais longo que o build.xml e isso não se afasta das convenções. De fato, meu exemplo do Maven é mostrado sem 54 linhas extras necessárias para configurar plugins. Esse pom.xml é para um projeto simples. O XML realmente começa a crescer significativamente quando você começa a adicionar requisitos extras, o que não é incomum para muitos projetos.
Mas você precisa dizer ao Ant o que fazer
Meu exemplo do Ant acima não está completo, é claro. Ainda precisamos definir os destinos usados para limpar, compilar, testar etc. Eles são definidos em um arquivo de compilação comum que é importado por todos os módulos no projeto de múltiplos módulos. O que me leva ao ponto de como todas essas coisas devem ser explicitamente escritas no Ant, enquanto são declarativas no Maven.
É verdade, me pouparia tempo se eu não tivesse que escrever explicitamente esses destinos Ant. Mas quanto tempo? O arquivo de compilação comum que eu uso agora é o que escrevi há 5 anos, com apenas alguns refinamentos desde então. Após meus 2 anos de experiência com o Maven, retirei o arquivo antigo de construção do Ant, tirei o pó e coloquei de volta no trabalho. Para mim, o custo de ter que dizer explicitamente a Ant o que fazer aumentou em menos de uma semana em um período de 5 anos.
Complexidade
A próxima grande diferença que eu gostaria de mencionar é a da complexidade e o efeito do mundo real que ela tem. O Maven foi criado com a intenção de reduzir a carga de trabalho de desenvolvedores encarregados de criar e gerenciar processos de compilação. Para fazer isso, tem que ser complexo. Infelizmente essa complexidade tende a negar o objetivo pretendido.
Quando comparado com o Ant, o desenvolvedor do projeto Maven gasta mais tempo:
- Lendo a documentação: Há muito mais documentação no Maven, porque há muito mais que você precisa aprender.
- Educar os membros da equipe: Eles acham mais fácil perguntar a alguém que sabe, em vez de tentar encontrar respostas.
- Solução de problemas de compilação: O Maven é menos confiável que o Ant, especialmente os plug-ins não essenciais. Além disso, as compilações do Maven não são repetíveis. Se você depende de uma versão SNAPSHOT de um plug-in, o que é muito provável, sua compilação pode ser interrompida sem que você tenha alterado nada.
- Escrevendo plug-ins do Maven: os plug-ins geralmente são escritos com uma tarefa específica em mente, por exemplo, criar um pacote de webstart, o que torna mais difícil reutilizá-los para outras tarefas ou combiná-los para atingir uma meta. Portanto, você pode precisar criar uma de sua preferência para solucionar as lacunas no conjunto de plug-in existente.
Em contraste:
- A documentação do Ant é concisa, abrangente e tudo em um só lugar.
- Formiga é simples. Um novo desenvolvedor que tenta aprender o Ant precisa entender apenas alguns conceitos simples (destinos, tarefas, dependências, propriedades) para poder descobrir o resto do que eles precisam saber.
- Formiga é confiável. Não houve muitos lançamentos do Ant nos últimos anos porque ele já funciona.
- As construções de formigas são repetíveis porque geralmente são criadas sem dependências externas, como repositórios online, plugins experimentais de terceiros etc.
- Ant é abrangente. Por ser uma caixa de ferramentas, você pode combinar as ferramentas para executar praticamente qualquer tarefa desejada. Se você precisar escrever sua própria tarefa personalizada, é muito simples.
Familiaridade
Outra diferença é a da familiaridade. Os novos desenvolvedores sempre precisam de tempo para se atualizar. A familiaridade com os produtos existentes ajuda nesse sentido e os apoiadores do Maven afirmam com razão que esse é um benefício do Maven. Obviamente, a flexibilidade do Ant significa que você pode criar as convenções que desejar. Portanto, a convenção que utilizo é colocar meus arquivos de origem em um nome de diretório src / main / java. Minhas classes compiladas vão para um diretório chamado target / classes. Parece familiar, não é?
Eu gosto da estrutura de diretórios usada pelo Maven. Eu acho que faz sentido. Também seu ciclo de vida de construção. Então, eu uso as mesmas convenções nas minhas construções do Ant. Não apenas porque faz sentido, mas porque será familiar para quem já usou o Maven antes.