ANT vs Maven vs Gradle

por

Antes de entrar em ANT, Maven ou Gradle, devemos primeiro entender poucas coisas relacionadas a eles.

Dependência: Em geral, uma dependência refere-se a quando algo requer alguma outra coisa para ser executado por si mesmo. Simplificando, ‘A’ tem dependência de ‘B’ se ‘A’ requer ‘B’ para a sua execução bem sucedida. No mundo do software, uma dependência é qualquer coisa que sua aplicação requer para sua execução com sucesso. É basicamente qualquer biblioteca de suporte externa requerida pela aplicação. Por exemplo, zuul, hystrix, lombok, jdbc, etc.

Inicialmente, nós usamos para gerenciar dependências por:

  • baixando o arquivo jar da biblioteca requerida manualmente da internet e adicionando-a ao nosso projeto.
  • escrevendo um script que automaticamente baixará a biblioteca de um fonte externa através da rede.

Problemas enfrentados antes destas ferramentas:

  • Adicionar as dependências baixando-as manualmente da internet é uma tarefa muito cansativa.
  • Nossos scripts podem falhar se a URL do fonte externo mudar através da internet.
  • É muito difícil identificar e gerenciar as dependências transitivas em nossa aplicação.

Ferramenta de gerenciamento de dependências: Resolve e gerencia as dependências requeridas pela aplicação.

Ferramenta de gestão de dependências: Automatiza a criação de aplicações executáveis a partir do código fonte. A construção incorpora a compilação, ligação e empacotamento do código em uma forma utilizável ou executável. Automação de compilação envolve:

  1. Download dependencies
  2. Compilar código fonte em código binário
  3. Empacotar aquele código binário
  4. Executar testes
  5. Empacotamento em sistemas de produção

Ferramentas de gerenciamento de dependência e compilação em java:

  • ANT + Ivy (2000/2004)
  • Maven (2004)
  • Gradle (2012)

Apache ANT (Another Neat Tool) é um projeto de código aberto pelo Apache, lançado no ano 2000. É uma biblioteca java utilizada para automatizar os processos de compilação de aplicações java. Também pode ser usada para a construção de aplicações não-java. Ela segue o princípio de “Configuração sobre convenção”. Em Ant, diferentes fases do processo de construção são chamadas de “Targets” (Alvos). Os arquivos de compilação ANT são escritos em XML e por convenção, eles são chamados “build.xml”. Ele contém três elementos: projeto, alvo e tarefa. Cada arquivo de compilação contém um projeto. Cada coisa no build.xml está sob o elemento projeto. O projeto contém pelo menos um target (padrão). O target contém um conjunto de tarefas dentro dele e define um estado específico do processo de compilação. Uma tarefa é um pedaço de código que pode ser executado. Cada nó pode ter atributos associados a eles:

Atributos do Project:

  • Nome: O nome do projeto.
  • Basedir: A pasta raiz do projeto e é opcional.
  • Default: O alvo padrão para a construção. O projeto pode ter um ou mais alvos. Ele é usado para especificar o alvo padrão do projeto.

Atributos do alvo:

  • Nome: O nome do alvo.
  • Descrição: Uma descrição sobre o alvo.
  • Depende: Lista de todos os alvos, separados por vírgula de que este alvo depende.
  • Se: O alvo é executado se o atributo for verdadeiro.
  • A menos que: O alvo é executado se o atributo não estiver definido.

Build.xml example:

<?xml version="1.0"?>
<project>
<target name="hello">
<echo>Hello, World</echo> 
</target>
</project>

Adicionar dependência em Ant + Ivy:

<dependency org="org.projectlombok" name="lombok" rev="1.18.10"/>

O principal benefício de Ant é a sua flexibilidade. O Ant não impõe nenhuma convenção de codificação ou estrutura de projeto ao desenvolvedor. Consequentemente, isto significa que o Ant requer que os desenvolvedores escrevam todos os comandos por eles mesmos, o que às vezes leva a grandes arquivos de compilação e são difíceis de manter. Inicialmente, o Ant não tinha suporte embutido para gerenciamento de dependência. Mais tarde ele adotou o Apache Ivy, desenvolvido como um sub-projeto do projeto Apache Ant, para o propósito de gerenciamento de dependências.

Apache Maven

É uma ferramenta de gerenciamento de dependências e automação de compilação, lançada em 2004. Ela continua usando XML, mas supera os inconvenientes seguindo o princípio da “Convenção sobre configuração”. Ela se baseia em convenções e fornece comandos pré-definidos (objetivos). Seu arquivo de configuração, contendo instruções de gerenciamento de compilação e dependência, é por convenção chamado “pom.xml” e está presente na pasta raiz do projeto.

>

>

Maven workflow

Maven engine toma o pom.xml e o projeto como inputs. Ele lê o arquivo pom.xml e baixa as dependências mencionadas nele como arquivos jarros para o repositório local. Em seguida, executa os ciclos de vida, fases de construção e plugins. No final, um artefato empacotado e testado é gerado.

pom.xml exemplo:

algumas tags importantes no arquivo pom.xml:

  • groupId: Representa a organização à qual o projecto pertence.
  • artifactId: É o nome do projecto.
  • versão: Representa a versão do projeto.
  • embalagem: Representa a forma final da construção do projeto. ex. jarro, war.

Adicionar dependência em maven:

<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.10</version>
</dependency>

Repositório Maven:

Um repositório é um diretório onde todos os arquivos do jarro empacotados existem junto com seus próprios arquivos pom. Esses arquivos pom contêm as dependências externas desse projeto. Desta forma o maven baixa recursivamente a dependência das dependências do seu projeto até que todas as dependências necessárias estejam presentes no seu repositório local. Existem três tipos de repositórios no maven:

  1. Repositório local: É um repositório presente na própria máquina do desenvolvedor.
  2. Repositório de nível/remoto de organização: É um repositório presente dentro da organização.
  3. Repositório central: É um repositório pela internet, criado e mantido pela comunidade maven.

Quando uma dependência é especificada no arquivo pom.xml de um projeto, a maven procura por ela no repositório local. Se ela não for encontrada lá, ela a procura no repositório remoto/org amplo. Se ela não está presente mesmo lá, então ela procura por ela no repositório central.

Maven prescreve uma estrutura de projeto rígida, enquanto Ant fornece flexibilidade lá também. Suas convenções rígidas vêm com o preço de ser muito menos flexível que o Ant – a customização de objetivos é muito difícil.

Drawbacks of maven:

  1. O gerenciamento de dependência não lida bem com conflitos entre diferentes versões de uma mesma biblioteca.
  2. Personalização de objetivos é difícil.

Gradle

É uma ferramenta de gerenciamento de dependência de código aberto e automação de construção, lançada em 2012. Ela combina as partes boas do Apache Ant e Apache Maven e constrói sobre eles e usa uma linguagem específica de domínio (baseada em Groovy) ao invés de XML. Ele adotou a flexibilidade do Ant e seu ciclo de vida do Maven. Ele também segue o princípio da “Convenção sobre a configuração”. Suporta os repositórios Maven e Ivy para a recuperação das dependências. Seu arquivo de configuração é por convenção conhecido como “build.gradle” e está presente na pasta raiz do projeto. Gradle deu o nome “tasks” aos seus passos de compilação, ao contrário dos “targets” do Ant ou “phases” do Maven. Google adotou Gradle como a ferramenta de construção padrão para Android OS.

Gradle não usa XML. Ao invés disso, ele tinha seu próprio Domain Specific Language baseado no Groovy (um dos idiomas da JVM). Como resultado, os scripts de construção Gradle tendem a ser muito mais curtos e claros do que os escritos para Ant ou Maven. A quantidade de código boilerplate é muito menor com Gradle.

Gradle configurations

  • implementation: É usado para declarar dependências que não queremos expor ao tempo de compilação dos nossos consumidores.
  • api: É usado para declarar dependências que fazem parte da nossa API, ou seja, para dependências que queremos expor explicitamente aos nossos consumidores.
  • compileOnly: Permite-nos declarar dependências que só devem estar disponíveis em tempo de compilação, mas que não são necessárias em tempo de execução. Um exemplo de caso de uso para esta configuração é um processador de anotações como o Lombok, que modifica o bytecode em tempo de compilação. Após a compilação não é mais necessário, portanto a dependência não está disponível em tempo de execução.
  • runtimeOnly: Ele nos permite declarar dependências que não são necessárias em tempo de compilação, mas que estarão disponíveis em tempo de execução. Um exemplo é SLF4J onde incluímos slf4j-api à configuração implementation e uma implementação dessa API (como slf4j-log4j12 ou logback-classic) à configuração runtimeOnly.
  • testImplementation: Similar a implementation, mas dependências declaradas com testImplementation só estão disponíveis durante a compilação e tempo de execução dos testes. Podemos usá-lo para declarar dependências a frameworks de teste como JUnit ou Mockito que só precisamos em testes e que não devem estar disponíveis no código de produção.
  • testCompileOnly: Similar a compileOnly, mas dependências declaradas com testCompileOnly só estão disponíveis durante a compilação dos testes e não em tempo de execução.
  • testRuntimeOnly: Similar a runtimeOnly, mas as dependências declaradas com testRuntimeOnly só estão disponíveis durante a compilação dos testes e não em tempo de compilação.

Projetos e tarefas em Gradle

Cada construção Gradle consiste em um ou mais projetos. Cada projeto consiste em um conjunto de tarefas. Cada tarefa representa um único trabalho que um build executa, por exemplo, gerar JavaDoc, publicar alguns arquivos em um repositório, etc.

Construir.gradle exemplo

Repositório Grade:

Os “apelidos” em Gradle são usados no caso de adicionar repositórios Maven ao build do nosso projeto. Estes apelidos são os seguintes:

  • mavenCentral(): Este alias significa as dependências que são obtidas do repositório central Maven 2.
  • jcenter(): Este alias significa as dependências que são obtidas do repositório JCenter Maven do Bintray.
  • mavenLocal(): Este alias significa as dependências que são obtidas do repositório Maven local.

Exemplo: adicione o repositório Maven central em nosso projeto, adicione o seguinte trecho de código ao nosso arquivo ‘build.gradle’:

repositories {
mavenCentral()
}

Adicionar dependência em Gradle:

compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'

Vantagens:

  1. Ele lida muito bem com dependências transitivas. Se existir uma dependência transitiva conflitante no projeto, então para resolvê-la, ele seleciona a versão mais recente da dependência. Por exemplo, a dependência ‘A’ internamente requer a dependência ‘C’ com a versão 2.0 e a dependência ‘B’ internamente requer a dependência ‘C’ com a versão 3.0. Então Gradle utilizará a última versão da dependência ‘C’.
  2. Os arquivos de configuração da Gradle são menores em tamanho e mais limpos, pois utiliza linguagem específica do domínio, baseada no Groovy em vez do XML.
  3. Gradle utiliza o conceito de compilação incremental e evita o trabalho ao rastrear a entrada e saída de tarefas e só executa o que é necessário, e só processa arquivos que mudaram quando possível e, portanto, executa mais rápido que maven.

Deixe um comentário