Maven vs Gradle : quem ganha, afinal?

Textinho técnico saindo do forno! Para facilitar o entendimento, grifei termos e palavras importantes.

Bem, sempre que eu aprendo algo novo, quero entender o contexto da ferramenta! Com o Gradle, claro, não foi diferente. E, mesmo já conhecendo o Maven, revisitei algumas coisas sobre o propósito dele para levantar seus diferenciais. O que eu quero? Saber quando um deles faz sentido em um projeto.


†

 

Muitas vezes, devs se preocupam um pouquinho mais com aspectos de implementação e execução do que aspectos de aplicabilidade ou arquiteturais. Por isso, trago alguns pontos sobre Maven e Gradle neste artigo e mais informações…

Bom, antes de tudo vamos começar com o Build.

O QUE É UM BUILD?

Vamos começar com aquele exemplo lúdico para, depois, considerarmos o aspecto técnico.

Considere que você quer, por exemplo, pedir uma pizza. Você precisa considerar, planejar e executar uma série de tarefas. Tipo definir de qual pizzaria vai pedir, o tamanho, os sabores, calcular o valor, se vai pedir via app ou ligação… e por aí vai…

Como eu conheço Java, vou traduzir o exemplo nessa linguagem. Basicamente, ao desenvolver utilizando Java, precisamos considerar que existem vários processos essenciais para que a gente consiga publicar/executar o sistema. Para isso, existem várias tarefas/processos que devemos considerar e, até mesmo, automatizar.

Existem também as etapas de checagem de dependência externas (bibliotecas de dependências), validação do código, coleta de métricas, execução de testes unitários, testes de integração, compilação e empacotamento. E chuta quem faz parte do Build? Isso aí: todas elas!

SOBRE EMPACOTAMENTO E PARTES IMPORTANTES DO BUILD:

A compilação é nada mais, nada menos que transformar o código Java em um tipo que seja interpretado pela JVM (Máquina virtual Java). E aqui estamos falando de bytecodes, que são a transformação do nosso código .java em um arquivo .class (por meio do Javac).

O empacotamento é quando todo seu código compilado é agrupado em um tipo de arquivo para sua execução, como por exemplo um .jar ou .war.

ALINHANDO EXPECTATIVAS

Provavelmente você não esperava esse tipo de conteúdo inicial, mas precisamos entender que o processo de Build pode variar muito de projeto para projeto. Cada empresa tem sua própria característica de ambiente, etapas adicionais e específicas quando falamos de build de software.

Agora que entendemos esse ponto crítico, vamos em frente!

VOLTANDO AO TECNIQUÊS…

Se você, em algum momento da sua bela vida de dev, precisou fazer um build manualmente ou criou soluções super “cool-e-inovadoras” para fazer isso… mesmo sabendo que isso não resolveria todos os seus problemas, você  certamente vê valor na automatização do processo de build e gerenciamento de dependências. E isso tem tudo a ver com Maven e o Gradle.

Mas antes de falarmos de Maven e Gradle vamos falar sobre Apache Ant?

A ferramenta, lançada em 2000, automatiza os processos de build e não tem gerenciamento de dependência. Então, muitas vezes, nos projetos era usada em conjunto com Ivy. Outro ponto do Ant é que ele permite que sejam criadas as especificações das tarefas do processo de build, chamadas de targets.

Utilizando o arquivo em XML, é possível configurar as etapas do seu build. Quando estamos falando de projetos pontuais, tudo bem. Mas, em projetos grandes, em que há muita configuração, o arquivo tende a ficar complexo e extenso. Muito extenso!

E nasceu o Maven

Com a chegada do Maven em 2005, foi possível configurar as dependências da aplicação em um só arquivo pom.xml e de forma bem simples de entender.Permite plugins para execução de tarefas específicas no processo de build e execução de outras ferramentas.

Isso facilita muito o gerenciamento de dependência, mas nem tudo são flores. Por ser um arquivo de configuração em XML, podemos repetir os mesmos problemas do Ant. Ou seja, o arquivo ainda tende a ficar extenso e complexo, com o passar do tempo. Especialmente em projetos grandes.

Um dos lemas do Maven é “Convenção sobre configuração”. Na prática, significa que existe um padrão. É o caso das fases de ciclo de build do Maven (fase é o nome da tarefa do processo de build), que são um padrão já existente.

Ai, Paula, não dá para configurar?

Calma, dá para fazer isso! Os plugins existem para permitir esta “adaptação” de execução de tarefas em meio às fases pré-definidas. Porém (porque sempre tem um porém), em projetos com características próprias, isso pode gerar um problemão. As chances de encontrar um plugin que faça exatamente o que você quer são remotas, pensando de uma forma SUPER POSITIVA! Aí você ainda vai ter que construir um, o que em muitas empresas é simplesmente inviável.

Vamos falar de coisa boa, então?

Com o Maven você pode criar modelos prontos de projetos, que chamamos de archetypes. Isso permite que você crie um start de um projeto de maneira mais simples e já na estrutura de pastas que o Maven utiliza. O que é uma verdadeira mão na roda para organizar o projeto. Hoje, podemos dizer que o Maven é o mais utilizado em projetos JAVA.

Vamos voltar ao exemplo da pizza. Já pensou se ninguém tivesse inventado a pizza meio a meio? Se você quisesse comer calabresa e mussarela, teria que pedir duas pizzas. E, talvez, sua fome nem fosse para tanto! É aí que entra o Gradle.

Meia calabresa, meia mussarela… inteira Gradle

Traduzindo para o técnico, o Gradle junta o que existe de bom no Maven e no Ant.

A ferramenta gerencia dependência e automatiza processo de build (assim como o Maven). Mas o bacana é que o Gradle não veio reinventar a roda. Ele permite que você utilize os repositórios do Maven, Ivy e até repositórios particulares. Assim, você trabalha junto com o Maven, com plugins e com amor no coração.

O Gradle possui os recursos do Maven e a flexibilidade do Ant. Cara, na boa, agora a gente olha para isso como uma evoluç!ao e não como uma mera concorrência.

O Gradle usa DSL em Groovy para criar o seu arquivo de configuração. É claro que, se você nunca utilizou nada parecido e quer começar a adotar essa tecnologia… bem, é preciso pensar na curva de aprendizagem.

Seu arquivo de configuração “build.gradle” permite uma programação das configurações, ou seja, você pode criar variáveis e utilizar lógica. Talvez seja um arquivo mais simples e fácil de configurar, até porque os comandos no Maven que exigiam linhas e linhas, são resumidos muitas vezes a uma linha só (que sonho de princesa).

As partes do processo de build que são chamadas de Goals no Maven e são pré definidas, são chamadas de Tasks no Gradle, possuindo algumas pré existentes e permitindo que você crie novas.

É exemplo que você quer? Então, toma!

Vamos utilizar um projeto Maven. Você vai executar o comando “install”, que é uma das fases pré-definidas do ciclo de vida default. Então, será iniciado o processo de build, com fases que o Maven deve executar antes da install.

Sempre existe uma ordem e fases fixas que serão executadas. O que você configura fora deste padrão será somente a execução dos plugins por fase.

O Gradle ficou conhecido por ser ferramenta padrão para projetos Android, além da adoção dele por parte de grandes empresas.

Além destes pontos, existe uma preocupação constante da equipe do Gradle em prover uma melhor experiência para o desenvolvedor. Por isso, cada vez mais as IDES oferecem um suporte cada vez mais completo para ele. Ele é considerada “leve” e possui uma interface de usuário que te deixa fazer depuração e otimização de compilação.

Uau, fala mais?

Apesar de ambas gerenciarem dependências, a maneira que cada uma trabalha é bem diferente.

O Maven permite substituir um arquivo no repositório local apenas um por versão. Além disso, não permite inclusão de regras por arquivo, o que muitas vezes resulta em uma dependência corrompida quando a origem está com problema, sendo preciso substituir manualmente por um arquivo de origem melhor.

O Gradle por sua vez fornece regras personalizáveis ​​de seleção e substituição de dependência que podem ser declaradas uma vez e então lidará com dependências indesejadas em todo o projeto. Além disso, ele também permite a execução paralela das tarefas do processo de build por meio de uma API do worker. O paralelismo é muito refinado, resultando em um desempenho mais rápido.

E a performance?

O Gradle tende a ter uma ótima performance quando comparado ao Maven. Em tempos de Continuous Delivery (Entrega Contínua) e Integração, cada segundo de performance conta. Para explicar melhor, destaco três melhorias específicas:

  • Incrementality : Evita o trabalho de rastrear entrada e resultado das Tasks (tarefas do build) e executa apenas o que é necessário, processando só os arquivos que mudaram desde o último build.
  • Cache de Execução: Reutiliza resultados de outro build efetuado que tenha as mesmas entradas, poupando esforços de fazer tudo do zero, inclusive entre máquinas.
  • Gradle Daemon: Um processo de longa duração que mantém as informações de builds “quentes” na memória. O Gradle analisa se o processo do Daemon está “de pé”, se não estiver inicia este processo e o mantém em execução. Ele ainda guarda informações do seu build! Ao fazer outro build, você perceberá a diminuição do tempo de execução, porque ele valida informações já existentes usando Cache de execução e não realiza o que não faz sentido. Sobre o processo continuar em execução pode soar assustador, não se preocupe: a opção é configurável – apesar de estar ativa por padrão.

A minha humilde opinião

Eu não os vejo como rivais, galera! Se, nessa altura do texto, você estiver amando um e arrancando o outro da sua vida… pare! Apenas foque em escolher o melhor para o projeto, para seus conhecimentos e para sua vida.

Nenhuma tecnologia é absoluta, combinado? 🙂

Resumo do rolê

Não fique preso à uma solução! Entenda as semelhanças e diferenças, o que cada um pode proporcionar e liberte-se. Já pensou em usar as duas soluções em conjunto, por exemplo? Vai que faz sentido para o seu momento, empresa, carreira…

Como ouvi recentemente de um colega no serviço:

“O Gradle não é um rival do Maven, na verdade ele veio para melhorar o que já existia!

Também acho muito importante analisar se as vantagens de migrar para o Gradle são maiores que permanecer no Maven.

Só não permita que o medo de aprender algo novo enfraqueça seus argumentos, te impedindo de usar algo que pode agregar valor ao seu trabalho! Assim como também não vale argumentar sobre inovação para usar algo novo no projeto, quando na verdade é só a ansiedade que a maioria dos desenvolvedores têm em usar tecnologias novas nos projetos.

Principais Tópicos

Maven

– Utiliza XML

– Utiliza convenções, além disso considera convenção sobre configuração

– Por convenção o nome do arquivo de configuração se chama pom.xml

– Trabalha com Plugins

– Possui um ciclo de vida composto fixo e por goals padrões

– Estrutura de diretórios padrão

– permite criação de archetype, um start para um modelo de projeto Maven

Gradle

– Utiliza DSL baseada no Groovy

– Utiliza convenções, porém permite flexibilidade

– Por convenção seu arquivo de configuração se chama build.gradle

– Trabalha com Plugins

– Utiliza conceito de tasks (tarefas), possui tasks prontas e permite que você crie as suas e monte seu ciclo

– Estrutura de diretórios padrão

– Altamente Configurável

Boa sorte, bom trabalho… e, se quiser, compartilhe comigo como é a sua experiência com as ferramentas! Vou adorar trocar figurinhas e dividir pontos de vista sobre as coisas.

Anúncios

Publicado por

Paula Santana

Desenvolvedora de software, atuo desde 2014 com desenvolvimento Java e recentemente passei pela Arquitetura de Soluções. Sou organizadora do Devs JavaGirl e SouJava, gosto de compartilhar conhecimento e aprender mais com outros profissionais.

3 comentários em “Maven vs Gradle : quem ganha, afinal?”

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s