Por que usar Gradle em vez de Ant ou Maven? [fechadas]


324

O que outra ferramenta de construção voltada para Java realmente me impressiona?

Se você usa o Gradle sobre outra ferramenta, por quê?


6
O Google entrou com o Gradle para android sdk. developers.google.com/events/io/sessions/325236644 . A Intellij agora adicionou suporte para gradle. Isso coloca Gradle em fluxo principal (e não apenas projectos de brinquedo)
Jayan

Os artefatos da primavera agora também são criados por Gradle, acho que o Hibernate é o mesmo.
Amir Pashazadeh

Respostas:


248

Eu não uso Gradle com raiva (apenas um projeto de brinquedo até agora) [autor significa que eles usaram Gradle apenas em um projeto de brinquedo até agora, não que Gradle seja um projeto de brinquedo - veja comentários] , mas eu diria que as razões pelas quais alguém consideraria usá-lo seriam as frustrações de Ant e Maven.

Na minha experiência, o Ant geralmente é somente para gravação (sim, eu sei que é possível escrever lindamente modulares, construções elegantes , mas o fato é que a maioria das pessoas não). Para qualquer projeto não trivial, torna-se alucinante e toma muito cuidado para garantir que construções complexas sejam verdadeiramente portáteis. Sua natureza imperativa pode levar à replicação da configuração entre compilações (embora as macros possam ajudar aqui).

O Maven adota a abordagem oposta e espera que você se integre completamente ao ciclo de vida do Maven. Usuários experientes do Ant consideram isso particularmente chocante, pois o Maven remove muitas das liberdades que você tem no Ant. Por exemplo, há um blog Sonatype que enumera muitas das críticas e respostas de Maven.

O mecanismo de plug-in Maven permite configurações de compilação muito poderosas, e o modelo de herança significa que você pode definir um pequeno conjunto de POMs pai encapsulando suas configurações de compilação para toda a empresa e projetos individuais podem herdar essas configurações, deixando-as leves. A configuração do Maven é muito detalhada (embora o Maven 3 prometa abordar isso), e se você quiser fazer algo que "não seja o jeito do Maven", precisará criar um plug-in ou usar a integração do hacky Ant. Note que gosto de escrever plugins do Maven, mas compreendo que muitos se oporão ao esforço envolvido.

Gradle promete atingir o ponto ideal entre Ant e Maven. Ele usa a abordagem de Ivy para resolução de dependências. Ele permite convenções sobre configuração, mas também inclui tarefas Ant como cidadãos de primeira classe. Também permite sabiamente usar repositórios Maven / Ivy existentes.

Portanto, se você acertou e ficou com algum dos pontos problemáticos do Ant / Maven, provavelmente vale a pena experimentar o Gradle, embora, na minha opinião, ainda deva ser visto se você não trocaria problemas conhecidos por problemas desconhecidos. A prova do pudim está na comida, portanto, eu reservaria julgamento até que o produto esteja um pouco mais maduro e outros tenham resolvido qualquer problema (eles o chamam de borda sangrenta por um motivo). Ainda vou usá-lo em meus projetos de brinquedos. É sempre bom estar ciente das opções.


69
@ Tom Não estava dizendo que Gradle é um projeto de brinquedos, mas que só o usei em um projeto de brinquedos até agora. Desculpe, você se sentiu enganado
Rich Seller

18
Sleer - apesar da idade, editei a postagem para esclarecer em linha o que é esclarecido nos comentários - o mal-entendido imediatamente classifica a postagem como anti-Gradle. Se alguém pesquisando Gradle (como eu) inicialmente entende mal a frase de abertura (como eu fiz), pode não ler muito mais ou ler o comentário esclarecedor (como eu quase fiz). Reverta / edite minha alteração se você não concordar / não gostar.
Bert F

48
Pelo que vale, eu não tive a impressão de que @RichSeller significava que Gradle era para projetos de brinquedos (mesmo antes de ler a peça entre colchetes).
precisa saber é o seguinte

2
Quando li "apenas um projeto de brinquedos até agora", instantaneamente tive a impressão de que o autor estava se referindo ao próprio Gradle como um projeto de brinquedos, especialmente depois da confusão "Não uso Gradle com raiva". Isso sugere que o autor usa Gradle quando não está com raiva. Sugiro apenas reescrever a primeira frase inteira.
Osa

79

O Gradle pode ser usado para muitos propósitos - é um canivete suíço muito melhor que o Ant -, mas é especificamente focado em construções de vários projetos.

Primeiro de tudo, Gradle é uma ferramenta de programação de dependência, o que também significa que é uma ferramenta de programação. Com o Gradle, você pode executar qualquer tarefa aleatória em sua configuração e o Gradle garantirá que todas as dependências declaradas sejam executadas de maneira adequada e oportuna. Seu código pode ser espalhado por vários diretórios em qualquer tipo de layout (árvore, plano, disperso, ...).

Gradle tem duas fases distintas: avaliação e execução. Basicamente, durante a avaliação, o Gradle procurará e avaliará os scripts de construção nos diretórios que deve procurar. Durante a execução, o Gradle executará tarefas que foram carregadas durante a avaliação, levando em consideração as interdependências da tarefa.

Além desses recursos de programação de dependência, o Gradle adiciona recursos de dependência de projeto e JAR por integração com o Apache Ivy. Como você sabe, Ivy é uma ferramenta de gerenciamento de dependências muito mais poderosa e muito menos opinativa do que o Maven.

Gradle detecta dependências entre projetos e entre projetos e JARs. Gradle trabalha com repositórios Maven (download e upload), como o iBiblio ou seus próprios repositórios, mas também suporta e outro tipo de infraestrutura de repositório que você possa ter.

Nas compilações de múltiplos projetos, o Gradle é adaptável e se adapta à estrutura e arquitetura da compilação. Você não precisa adaptar sua estrutura ou arquitetura à sua ferramenta de construção, como seria necessário com o Maven.

Gradle tenta muito não atrapalhar, um esforço que Maven quase nunca faz. A convenção é boa, mas também a flexibilidade. O Gradle oferece muito mais recursos do que o Maven, mas o mais importante é que, em muitos casos, o Gradle oferecerá um caminho de transição indolor para o Maven.


64

Isso pode ser um pouco controverso, mas Gradle não esconde o fato de que é uma linguagem de programação completa.

Ant + ant-contrib é essencialmente uma linguagem de programação completa, na qual ninguém realmente deseja programar.

O Maven tenta adotar a abordagem oposta de tentar ser completamente declarativo e forçar você a escrever e compilar um plug-in se precisar de lógica. Também impõe um modelo de projeto que é completamente inflexível. Gradle combina o melhor de todas essas ferramentas:

  • Segue convenção sobre configuração (ala Maven), mas apenas na extensão que você desejar
  • Permite escrever tarefas personalizadas flexíveis, como no Ant
  • Ele fornece suporte a projetos com vários módulos, superior ao Ant e Maven
  • Ele possui uma DSL que facilita os 80% e os 20% possíveis (ao contrário de outras ferramentas de compilação que facilitam os 80%, 10% possíveis e 10% efetivamente impossíveis).

Gradle é a ferramenta de compilação mais configurável e flexível que ainda tenho que usar. É necessário algum investimento inicial para aprender o DSL e conceitos como configurações, mas se você precisar de uma ferramenta de construção da JVM totalmente absurda e completamente configurável, é difícil de superar.


49

Gradle combina bem Ant e Maven, tirando o melhor dos dois frameworks. Flexibilidade do Ant e convenção sobre configuração, gerenciamento de dependência e plugins do Maven.

Portanto, se você deseja ter uma compilação java padrão, como no maven, mas a tarefa de teste precisa executar alguma etapa personalizada, pode ser semelhante a seguir.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

Além disso, ele usa sintaxe groovy, que oferece muito mais poder de expressão do que o xml de ant / maven.

É um superconjunto do Ant - você pode usar todas as tarefas do Ant em gradle com uma sintaxe mais agradável e do tipo groovy, ou seja.

ant.copy(file:'a.txt', toDir:"xyz")

ou

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

35

Usamos Gradle e escolhemos entre Maven e Ant. Ant nos deu total flexibilidade, e Ivy oferece melhor gerenciamento de dependência que o Maven, mas não há grande suporte para compilações de vários projetos. Você acaba codificando bastante para suportar compilações de vários projetos. Também é bom ter uma construção por convenção e tornar os scripts de construção mais concisos. Com o Maven, a construção por convenção leva muito longe e a personalização do processo de construção se torna um hack. Além disso, o Maven promove todos os projetos que publicam um artefato. Às vezes, você tem um projeto dividido em subprojetos, mas deseja que todos os subprojetos sejam construídos e versionados juntos. Não é realmente algo para o qual o Maven seja projetado.

Com o Gradle, você pode ter a flexibilidade do Ant e construir por convenção do Maven. Por exemplo, é trivial estender o ciclo de vida da construção convencional com sua própria tarefa. E você não é forçado a usar uma convenção, se não quiser. Groovy é muito mais agradável de codificar que XML. No Gradle, é possível definir dependências entre projetos no sistema de arquivos local sem a necessidade de publicar artefatos para cada um em um repositório. Por fim, Gradle usa Ivy, por isso possui excelente gerenciamento de dependências. A única desvantagem real para mim até agora é a falta de integração madura do Eclipse, mas as opções para o Maven não são realmente muito melhores.


2
Pessoalmente, acho que a integração do Eclipse está bem. Instalá-lo no Juno é bastante simples.
djangofan

1
2 anos depois que o autor escreveu esta resposta!
Dennis

21

Esta não é a minha resposta, mas definitivamente ressoa comigo. É do Radar de Tecnologia da ThoughtWorks de outubro de 2012 :

Duas coisas causaram fadiga nas ferramentas de construção baseadas em XML, como Ant e Maven: muitas chaves pontiagudas irritadas e a grosseria das arquiteturas de plug-in. Embora os problemas de sintaxe possam ser tratados através da geração, as arquiteturas de plug-in limitam severamente a capacidade das ferramentas de construção crescerem graciosamente à medida que os projetos se tornam mais complexos. Concluímos que os plug-ins são o nível errado de abstração e preferimos ferramentas baseadas em idiomas como Gradle e Rake, porque oferecem abstrações de granularidade mais fina e maior flexibilidade a longo prazo.


16

Gradle colocou a diversão de volta na construção / montagem de software. Eu usei o ant para criar software em toda a minha carreira e sempre considerei a parte "buildit" real do trabalho do desenvolvedor como um mal necessário. Alguns meses atrás, nossa empresa se cansou de não usar um repositório binário (também conhecido como check-in de frascos nos vcs) e me foi dada a tarefa de investigar isso. Começou com a hera, uma vez que poderia ser aparafusada em cima da formiga, não teve muita sorte em publicar meus artefatos construídos como eu queria. Eu fui pro maven e cortei com xml, trabalhei esplêndido para algumas bibliotecas auxiliares simples, mas tive problemas sérios ao tentar empacotar aplicativos prontos para implantação. Peguei bastante tempo pesquisando plugins no Google e lendo fóruns e acabei baixando trilhões de frascos de suporte para vários plugins que tive dificuldade em usar.

Mas desde o primeiro dia meu humor começou a melhorar. Eu estava chegando a algum lugar. Demorei duas horas para migrar meu primeiro módulo ant, e o arquivo de compilação era basicamente nada. Uma tela facilmente montada. O grande "uau" foi: criar scripts em xml, quão estúpido é isso? o fato de que declarar uma dependência ocupa UMA linha é muito atraente para mim -> você pode ver facilmente todas as dependências de um determinado projeto em uma página. A partir de então, eu andava constantemente, pois para todos os problemas que enfrentava até agora, havia uma solução simples e elegante. Eu acho que estas são as razões:

  • groovy é muito intuitivo para desenvolvedores java
  • documentação é ótima para impressionante
  • a flexibilidade é infinita

Agora passo meus dias tentando pensar em novos recursos para adicionar ao nosso processo de compilação. Quão doente é isso?


+1 para "criar scripts em xml, como isso é estúpido?" Em 2000, XML era considerado a coisa mais legal de todas, então, com toda a justiça, parecia mais moderno do que estúpido na época. Linguagens de programação baseadas em XML são basicamente lisps porque possuem delimitadores de abrir / fechar para cada comando. Mas são versões super verbosas do lisp, onde 4 caracteres de código se tornam 40 caracteres. É uma maneira de aprender a digitar, mas não a minha xícara de chá.
precisa saber é o seguinte

8

Também é muito mais fácil gerenciar construções nativas. Ant e Maven são efetivamente somente Java. Existem alguns plugins para o Maven que tentam lidar com alguns projetos nativos, mas eles não fazem um trabalho eficaz. Podem ser escritas tarefas Ant que compilam projetos nativos, mas são muito complexas e complicadas.

Fazemos Java com JNI e muitos outros bits nativos. Gradle simplificou consideravelmente nossa bagunça Ant. Quando começamos a introduzir o gerenciamento de dependências nos projetos nativos, era uma bagunça. Conseguimos que o Maven fizesse isso, mas o código Gradle equivalente era uma pequena fração do que era necessário no Maven, e as pessoas podiam lê-lo e entendê-lo sem se tornarem gurus do Maven.


3

Concordo parcialmente com Ed Staub. Definitivamente, o Gradle é mais poderoso em comparação com o maven e fornece mais flexibilidade a longo prazo.

Depois de realizar uma avaliação para passar de maven para gradle, decidimos manter o próprio maven por dois problemas que encontramos com gradle (a velocidade é mais lenta que o maven, o proxy não estava funcionando).


Eu tive problemas de proxy com a v1.2, mas desde então acho que está funcionando. Tanto assim, o ctnlm ou aplicativo como esse é uma solução para o maven resolver problemas de proxy do NTLM. Gradle tem esse suporte pronto para uso. embora isso seja tão trivial, eu me pergunto por que o Maven nunca teve esse suporte pronto para uso em proxies baseados em autenticação NTLM.
Skipy #
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.