Precisaremos de qualquer coisa com java, então vamos começar bem ordinários.
Reza a lenda que tudo começou após o Monolito Negro (que não é negro mas enfim) nos explicar como automatizar o processo de construção dos programas usando o Make. Passaram-se as eras, e o conhecimento dos antigos se perdeu, e incapazes de fazer um Makefile que prestasse os adeptos do Java criaram o Ant.
Eu vou assumir que você baixou o ant e ele está disponível na linha de comando após você ajustar as variáveis de ambiente. O nosso projeto ganha agora o arquivo build.xml. Ele tem um target que sabe como compilar e empacotar nosso projeto. Só precisamos rodar o comando "ant" e teremos o jar rodando:
Como?! Rodar testes? Sem problemas, baixamos manualmente o junit, escrevemos o teste e criamos um target no build.xml pra rodar isso, conforme pode ser visto aqui.
Os testes executados geram um relatório:
A época dos ant builds ecoa até hoje. Funcionam. Mas com a chegada d'Ele tudo mudou. A começar pela estrutura de pastas, que sai disso aqui para isso aqui.
E não usamos mais o build.xml, agora é pom.xml. Nele não definimos targets, ele já sabe que nós queremos empacotar java e resolver dependências.
Supondo o maven disponível no path do seu sistema, basta mandar um "mvn install" pra magia acontecer:
O bacana e talvez o maior legado do maven é que você não precisa mais fazer no braço o download das bibliotecas que for usar. Ele baixa por você. Ele tem espelhos contendo toda a produção java relevante feita pela humanidade e outros. Ele faz mais coisas, mas não se empolgue muito não. Guarde essa empolgação aí pro que vem agora.
O gradle é a menina bonita da festa. Apoiando-se onde os outros acertaram e inovando onde outros erraram, coloca mais uma pá de solução no problema de construir e testar seu projeto java. Olhe a saída do comando "gradle build" como é limpa:
O script de construção, o build.gradle, é o mais simples da história, rivalizando com a simplicidade de um Makefile.
Assim como seus antecessores, ele gera relatórios dos testes, mas faz isso dum jeito bonito:
Simples assim.
De modo resumido, vai começar um projeto novo em java? use gradle.
Das três abordagens apresentadas, apenas duas resolvem automaticamente as dependências de um projeto: gradle, e maven. Como?! resolução de dependência é frescura? Pois resolva manualmente todas as dependências de um projeto JEE/Spring regular que vá de relatórios a mensageiras jms.
Mas projetos Ant estão fadados a depender de um engenheiro sênior para resolver isso? Talvez não.
O Ivy está aqui pra entregar ao Ant a mesma facilidade introduzida pelo maven (que roubou a ideia do app store, que roubou a ideia do apt-get, mas isso é outro assunto), mantendo as velhas e conhecidas tasks da formiguinha.
Pra colocar ele pra trabalhar, vamos modificar nosso build.xml de modo que ele baixe o ivy magicamente e depois passe a gerenciar o download das dependências. Aquela pasta de bibliotecas deixa de existir.
O builld não é afetado, bastando digitar o mesmo comando "ant" de sempre:
Só a saída que ficou a mais feia de todas, só perdendo em feiura para a saida do npm install (que é outra história que falamos depois).
E é isso.
Como?! Ah, boa pergunta. Se tem eclipse, netbeans, vim e intellij, por que que eu vou me preocupar com uma parada dessas?
A resposta para isso é simples: IDE's são pensadas pra ser usadas por seres humanos. Nem todos os membros da sua equipe são seres humanos (não... não falo do seu chefe!)
Bots como hudson, jenkins, teamcity e vários outros são parte do time e te ajudam a empacotar tudo e garantir que tudo funciona. E pra esses caras o ideal é um script simples que nem esses dados de exemplo aqui.
E é isso, falou, até mais.
Nenhum comentário :
Postar um comentário