Eu tweeto conteúdo técnico que considero interessante, mas os tweets engraçados são os que mais engajam. Participei da conferência JavaLand em março, tropecei no estande do Gradle e encontrei esta joia:   Claro, em algum momento, um fanboy sequestrou o tópico e reivindicou a   Neste post, gostaria de lançar alguma luz sobre minha posição, para que eu possa direcionar as pessoas a ela, em vez de desmascarar o mesmo "raciocínio" repetidamente. chamada superioridade de Gradle.  Para administrar isso, preciso voltar no tempo. O desenvolvimento de software é um campo em rápida mudança e muito do nosso entendimento é baseado na experiência pessoal. Então aqui está o meu.  Minha primeira ferramenta de construção: Ant   Comecei   em 2002. Na época, não havia ferramentas de construção: compilamos e construímos através do IDE. Só para constar, primeiro usei o Visual Age for Java; então, mudei para o Borland JBuilder. a desenvolver em Java  Construir com um IDE tem um grande problema: cada desenvolvedor tem configurações dedicadas, então a geração do artefato depende da combinação desenvolvedor-máquina.  Compilações não repetíveis são um problema antigo. Minha primeira experiência com compilações repetíveis é Apache Ant:  Apache Ant é uma biblioteca Java e ferramenta de linha de comando cuja missão é conduzir processos descritos em arquivos de construção como alvos e pontos de extensão dependentes uns dos outros. O principal uso conhecido do Ant é a construção de aplicativos Java. O Ant fornece várias tarefas integradas que permitem compilar, montar, testar e executar aplicativos Java. O Ant também pode ser usado efetivamente para construir aplicativos não Java, por exemplo, aplicativos C ou C++. De forma mais geral, o Ant pode ser usado para pilotar qualquer tipo de processo que possa ser descrito em termos de alvos e tarefas.  --  https://ant.apache.org/  Ant é baseado em três abstrações principais:  Uma   é uma unidade atômica de trabalho,   ,   para compilar arquivos Java,   para montar um arquivo da Web, etc. Ant fornece muitas tarefas prontas para uso, mas permite adicionar outras personalizadas. tarefa por exemplo javac war  Um   é uma lista de tarefas. destino  Você pode definir dependências entre tarefas, como   dependente de   . A esse respeito, você pode ver Ant como um mecanismo de execução de fluxo de trabalho. pacote compilação  Logo me tornei "fluente" em Ant. Como consultor, fui de empresa em empresa, projeto em projeto. Inicialmente, eu configurei principalmente o Ant, mas o Ant se tornou mais difundido com o passar do tempo e encontrei configurações Ant existentes. Eu era consistente em meus projetos, mas outros projetos eram muito diferentes uns dos outros.  Toda vez, ao chegar a um novo projeto, você tinha que ler cuidadosamente a configuração do Ant para entender a construção personalizada. Além disso, a estrutura de cada projeto era diferente. Alguns colocam suas fontes em   , alguns em   , alguns em uma estrutura aninhada, etc. src sources  Lembro-me de um arquivo de construção genérico que tentava acomodar todas as necessidades de projeto de uma organização. Ele definiu mais de 80 alvos em mais de 2.000 linhas de XML. Levei um tempo não trivial para entender como usá-lo com ajuda e ainda mais tempo para poder ajustá-lo sem interromper os projetos.  Minha segunda ferramenta de construção: Maven   O projeto acima me fez pensar muito. Eu queria melhorar a situação, pois os mantenedores já haviam ultrapassado os limites do Ant. Na época, eu estava trabalhando com meu amigo   (famoso pelo Sonar). Conversamos e ele me indicou Maven. Certa vez   , mas não tinha outra experiência anterior. Estudei a documentação por horas e, por meio de tentativas de tentativa e erro, sob a tutela de Freddy, migrei todo o arquivo de construção do Ant para um POM pai simples. Freddy Mallet , construí um projeto com Maven  No Ant, você precisaria definir tudo em cada projeto. Por exemplo, o Ant requer a configuração do local dos arquivos Java para compilação; O Maven assume que eles estão em   , embora seja possível substituí-lo. O Maven revolucionou o campo de construção Java com sua abordagem   . Hoje em dia, muitos softwares oferecem configurações sensatas por padrão. src/main/java Convenção sobre Configuração  Para desenvolvedores que vão de projeto em projeto, como eu fiz, isso significa que há muito menos carga cognitiva ao ingressar em um novo projeto. Espero que as fontes Java estejam localizadas em   . As convenções do Maven continuam além da estrutura do projeto. Eles também definem o ciclo de vida do projeto, desde a compilação até o upload do artefato em um registro remoto, por meio de testes de unidade e integração. src/main/java  Por fim, os desenvolvedores juniores tendem a ignorar isso, mas Maven definiu o termo   . Ele introduziu a ideia de registros de artefatos, de onde é possível baixar dependências imutáveis e enviar artefatos. Antes disso, cada projeto tinha que armazenar dependências em seu repositório dedicado. gerenciamento de dependência  Para registro, havia algumas dependências armazenadas no projeto mencionado acima. Quando migrei do Ant para o Maven, tive que encontrar a versão exata da dependência. Para a maioria, era simples, como no nome do arquivo ou no manifesto do JAR. Um, no entanto, foi atualizado com classes adicionais.  Tanto para a imutabilidade.  O Maven teve uma profunda influência em todas as ferramentas de construção posteriores: elas se definiram em referência ao Maven.  Nenhuma ferramenta de construção minha: Gradle   A principal reivindicação de Gradle era corrigir as deficiências de Maven, ou pelo menos o que ele percebia como tal. Embora o Maven não esteja isento de censura, Gradle assumiu que o problema mais significativo era sua falta de flexibilidade. É uma suposição surpreendente, porque foi exatamente isso que o Maven melhorou em relação ao Ant. Os projetos Maven têm estruturas semelhantes e usam o mesmo ciclo de vida: o   em vigor. Por outro lado, o Gradle permite personalizar quase todos os aspectos da compilação, incluindo o ciclo de vida. princípio da menor surpresa  Antes de confrontar o argumento da flexibilidade, deixe-me reconhecer dois ótimos recursos originais do Gradle que o Maven implementou posteriormente: o daemon do Gradle e o wrapper do Gradle.  Maven e Gradle são aplicativos Java executados na JVM. Iniciar uma JVM é caro em termos de tempo e recursos. O benefício é que a JVM de execução longa otimizará o código JIT-ed ao longo do tempo. Para tarefas de curto prazo, o benefício é zero e até prejudicial se você levar em consideração o tempo de inicialização da JVM. Gradle surgiu com o daemon Gradle. Quando você executar o Gradle, ele procurará um daemon em execução. Caso contrário, ele iniciará um novo. O aplicativo de linha de comando delegará tudo ao daemon. Como o próprio nome indica, o daemon não para quando a linha de comando termina. O daemon aproveita os benefícios da JVM.  As chances são de que seu aplicativo sobreviverá às suas ferramentas de construção atuais. O que acontece quando você precisa consertar um bug daqui a cinco anos, apenas para perceber que a ferramenta de construção do projeto não está disponível online? A ideia por trás do wrapper do Gradle é manter a versão exata do Gradle junto com o projeto e apenas o código suficiente para baixar a versão completa pela Internet. Como efeito colateral, os desenvolvedores não precisam instalar o Gradle localmente; todos usam a mesma versão, evitando qualquer discrepância.  Desmistificando a flexibilidade do Gradle  O Gradle trouxe os dois ótimos recursos acima que o Maven integrou, provando que a concorrência é boa. Apesar disso, ainda não encontro nenhum benefício do Gradle.  Vou tentar afastar o lado emocional. No início, o marketing da Gradle tentou rebaixar Maven em todas as ocasiões possíveis, publicou gráficos de comparação malucos e geralmente era   agressivo em sua comunicação. Digamos que essa fase durou muito mais do que seria aceitável para uma jovem empresa em busca de seu lugar no mercado. Você poderia dizer que Gradle era muito edipiano em sua abordagem: tentando matar seu "pai" Maven. Finalmente, depois de todos esses anos, parece que ele se deu conta e agora "ama Maven". muito  Lembre-se de que antes de Maven assumir, todo projeto Ant era ad hoc. Maven acabou com isso. Ele trouxe a lei para o Velho Oeste Mundial de projetos personalizados. Você pode discordar da lei, mas é a lei de qualquer maneira, e todos precisam respeitá-la. Os padrões do Maven são tão arraigados que, embora seja possível sobrescrever alguns parâmetros,   , local de origem, ninguém nunca o faz. por exemplo  Eu experimentei dois sintomas da flexibilidade de Gradle. Suspeito que existam muito mais.  Fases personalizadas do ciclo de vida  O Maven gerencia o teste de integração em quatro fases, executadas na ordem:    : configure tudo o que os testes precisam pre-integration-test    : executa os testes integration-test    : limpe os recursos, se houver post-integration-test    : agir de acordo com os resultados dos testes verify  Nunca usei as fases pré e pós, pois cada teste tinha uma lógica dedicada de configuração e desmontagem.  Por outro lado,   . No entanto, os fanboys do Gradle terão prazer em explicar que você pode adicionar as fases que desejar. De fato, o Gradle permite a "personalização" do ciclo de vida: você pode adicionar quantas fases extras quiser ao ciclo de vida regular. Gradle não tem nenhuma noção de testes de integração  É uma bagunça, pois cada projeto precisará apresentar o número de fases necessárias e seu nome:   ,   ,   ,   (para os preguiçosos) etc. As opções são infinitas. integration-test integration-tests integration-testing it  A síndrome do floco de neve  O Maven trata cada projeto como um projeto padrão regular. E se você tiver necessidades específicas, é possível escrever um plugin para isso. Escrever um plug-in Maven definitivamente não é divertido; portanto, você só escreve um quando é necessário, não apenas porque decidiu que a lei não se aplica a você.  Gradle afirma que a falta de flexibilidade é um problema; portanto, ele deseja corrigi-lo. Eu defendo o oposto: a falta de flexibilidade para minha ferramenta de construção é um recurso, não um bug. Gradle torna mais fácil hackear o build. Portanto, qualquer pessoa que pense que seu projeto é um floco de neve especial e que merece personalização o fará com prazer. Verificação da realidade: raramente é o caso; quando é, é para frameworks, não para projetos regulares. Os proponentes do Gradle dizem que ele ainda oferece padrões, permitindo uma configuração fácil. O cerne da questão é que não é um padrão se pode ser alterado por capricho de qualquer pessoa.  Gradle é a ferramenta de compilação   para   . Em uma das empresas em que trabalhei, alguém escreveu um código Groovy personalizado na compilação Gradle para executar o Sonar e enviar as métricas para a instância interna do Sonar. Não havia nenhum plug-in Sonar pronto para uso na época, ou presumo que não tenha funcionado. Até agora tudo bem. de fato projetos Android  Quando outra equipe criou o segundo projeto Android da empresa, eles copiaram e colaram a estrutura do primeiro projeto e o arquivo de construção. A coisa inteligente a fazer teria sido, neste momento, criar um plug-in interno do Gradle a partir do código específico do Sonar. Mas eles não fizeram isso porque o Gradle tornou muito fácil hackear a compilação. E eu, o odiador de Gradle, decidi criar o plug-in. Poderia ter sido uma experiência de desenvolvedor melhor, para dizer o mínimo. Na falta de documentação de qualidade e usando uma linguagem não tipada (Groovy), usei o console para imprimir a estrutura dos objetos para progredir.  Conclusão  A concorrência é boa e o Gradle trouxe novas ideias que o Maven integrou, o wrapper e o daemon. No entanto, o Gradle é construído com base na premissa de que a flexibilidade é boa, enquanto minha experiência me mostrou o contrário. Ant era muito flexível e a carga cognitiva para ir de um projeto para o outro era alta.  Nós, desenvolvedores, somos seres humanos: gostamos de pensar que nossos projetos são diferentes dos outros. Na maioria das vezes, eles não são. A personalização é apenas uma forma de satisfazer o nosso ego. Ferramentas de construção flexíveis nos permitem implementar essa personalização, garantida ou não.  Personalizações irrelevantes não trazem nenhum benefício e são fáceis de desenvolver, mas caras de manter. Se o gerenciamento de ativos de software fizer parte de minhas responsabilidades, sempre escolherei estabilidade em vez de flexibilidade para minha ferramenta de construção.   Originalmente publicado em   em 6 de agosto de 2023 A Java Geek

This story contains new, firsthand information uncovered by the writer.

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este áudio é produzido no idioma original da história!

O Gradle é realmente melhor que o Maven? - Meu veredicto final

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Uma breve introdução à teoria do cérebro de Boltzmann

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Uma breve introdução à teoria do cérebro de Boltzmann

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps