Conhecendo Gradle — Comparação
Se você já lidou com sistemas de compilação, a frustração pode ser um dos sentimentos que surge e te domina em grande parte do tempo quando se pensa sobre os desafios que você enfrentou. A ferramenta de construção naturalmente não deveria ajudá-lo a realizar o objetivo de automatizar o seu projeto? Em vez disso, você teve que comprometer a capacidade de manutenção, facilidade de utilização, flexibilidade, extensibilidade, ou desempenho para fazer essa automatização.
Vamos dizer que você deseja copiar um arquivo para um local específico quando você está construindo a versão de lançamento do seu projeto. Para identificar a versão, você verifica informações nos metadados descrevendo seu projeto. Se ele corresponde a um esquema de numeração específico (por exemplo, 1.0-RELEASE), você copia o arquivo do ponto A ao ponto B. A partir de uma perspectiva de fora, isso pode soar como uma tarefa trivial. Se você tem que confiar em XML, a linguagem de construção de muitas ferramentas tradicionais, expressando essa lógica simples torna-se bastante difícil de implementar e de ler no arquivo. A resposta da ferramenta de construção é adicionar a funcionalidade de scripts através de mecanismos de extensão fora do padrão. Você acaba misturando código de script com XML ou invoca- scripts externos da sua lógica de construção. É fácil imaginar que você vai precisar adicionar mais e mais código personalizado ao longo do tempo. Como resultado, você inevitavelmente irá introduzir complexidade acidental e manutenção fica mais difícil, por não ser padronizada em todas as empresas. Não faria sentido usar uma linguagem expressiva para definir sua lógica de construção em primeiro lugar?
A evolução das ferramentas de Build para Java
Vejamos como ferramentas de construção têm evoluído ao longo dos anos. Duas ferramentas têm dominado projetos Java construção: ANT e Maven. Ao longo de anos, ambas as ferramentas melhoraram significativamente e estenderam seu conjunto de recursos. Mas mesmo que ambos são altamente populares e se tornaram padrões da indústria, eles têm um ponto fraco: construir a lógica tem de ser descrito em XML. XML é bom para descrever dados hierárquicos, mas deixa a desejar em expressar o fluxo do programa e lógica condicional. Como um script de construção cresce em complexidade, manter o código de construção torna-se um pesadelo.
A primeira versão oficial do ANT foi lançada em 2000. Cada elemento do trabalho [um alvo (target) no vocabulário do ANT] podem ser combinados e reutilizados. Múltiplos alvos podem ser encadeados para combinar unidades individuais de trabalho em fluxos de trabalho completos. Por exemplo, você pode ter um alvo para compilar o código-fonte Java e outro para a criação de um arquivo JAR que empacota os arquivos de classe. Construindo um arquivo JAR só faz sentido se você compilado pela primeira vez o código-fonte. Em ANT, você faz o alvo JAR depender do destino de compilação. O ANT não dá qualquer orientação sobre como estruturar seu projeto. Embora permite a máxima flexibilidade, o ANT faz com que cada script de construção único e difícil de entender. As bibliotecas externas para seu projeto normalmente são enviadas ao controle de versão, porque não há nenhum mecanismo automatizado para puxá-los a partir de uma localização central. As primeiras versões do ANT exigiam muita disciplina para evitar código repetitivo. Seu mecanismo de extensão era fraco. Como resultado, a prática de codificação ruim de copiar e colar código era a única opção viável. Para unificar layouts do projeto, as empresas eram obrigadas a criar e impor padrões internos.
A versão 1.0 do Maven, lançado em julho de 2004, tentou aliviar esse processo. Ele forneceu um projeto padronizado e estrutura de diretório, bem como gerenciamento de dependência. Infelizmente, a lógica personalizada é difícil de implementar. Se você quiser sair de convenções de Maven, escrever um plugin, chamado Mojo, é geralmente a única solução. O nome Mojo poderia implicar uma maneira simples, fácil e sexy para estender Maven; na realidade, escrever um plugin no Maven é trabalhoso e excessivamente complexo.
Mais tarde, ANT alcançando o Maven, por meio da introdução de gerenciamento de dependência através da biblioteca Apache Ivy, que pode ser totalmente integrado com ANT para especificar declarativamente dependências necessárias para o processo de compilação e empacotamento do seu projeto. O gerenciador de dependência do Maven, assim como Ivy, suporta resolver dependências transitivas. Quando falo de dependências transitivas, quero dizer os grafos de bibliotecas exigido por suas dependências especificadas. Um exemplo típico de uma dependência transitiva seriam os Xerces biblioteca de analisador XML que requer a biblioteca de APIs XML para funcionar corretamente. Maven 2, lançado em outubro de 2005, teve a ideia de convenção sobre configuração mais além. Projetos que consistem em vários módulos poderiam definir suas dependências entre si.
Nos dias de hoje uma grande quantidade de pessoas estão procurando alternativas para as ferramentas de compilação. Vemos uma mudança do uso de XML para uma linguagem mais expressiva e legível para definir a construção. A ferramenta de construção que transporta a ideia é GANT, uma DSL em cima ANT escrito em Groovy. Usando GANT, os usuários agora podem combinar características Groovy com seu conhecimento existente de ANT sem ter que escrever XML. Mesmo não fazendo parte do projeto core do Maven, uma abordagem semelhante foi proposta pelo projeto Maven Poliglota que permite que você escreva sua lógica de definição de compilação, que é o arquivo objeto de projeto do modelo (POM), em Groovy, Ruby, Scala ou Clojure.
Estamos no limiar de uma nova era de desenvolvimento de aplicações: programação e persistência poliglota. Muitos aplicativos hoje incorporam várias linguagens de programação, cada um dos quais é o mais adequado para implementar um domínio de problema específico. Não é incomum enfrentar projetos que utilizam linguagens do lado do cliente como JavaScript que se comunicam com um back-end mista, multilíngue como Java, Groovy e Scala, que por sua vez faz chamadas para um aplicativo herdado C++. É tudo sobre a ferramenta certa para o trabalho. Apesar dos benefícios da combinação de várias linguagens de programação, a sua ferramenta de Build precisa de apoio fluentemente e infraestrutura também. JavaScript precisa ser incorporada, minified, e compactado, e seu lado servidor e código legado precisa ser compilado, embalados e implantado.
Gradle se encaixa perfeitamente no que a geração de ferramentas de compilação e satisfaz muitos requisitos de ferramentas de construção modernos. Ele fornece uma DSL expressivo, uma convenção sobre a abordagem de configuração e gerenciamento de dependência poderosa. Faz o movimento certo para abandonar XML e introduzir a linguagem dinâmica Groovy para definir sua lógica de construção. Soa convincente, não é?
