O Ant ainda está no "mainstream" para compilações Java?

14

Substituímos lentamente os arquivos de comando em lote (windows .bat), que estavam simplesmente estragando as classes compiladas no IDE do desenvolvedor, com versões mais abrangentes do Ant (ou seja, obtidas do CVS, compilação limpa, jar, archive, email, etc.)

Passei muito tempo aprendendo (e depurando) problemas com o Ant, por isso estou mais confortável em usá-lo para essas tarefas. Mas me pergunto se o Ant ainda está em uso tão amplo quanto quando comecei a aprender, ou se "o mundo mudou" para algo mais novo (e talvez mais esperto). (Comecei a ver mais coisas do Maven construídas distribuídas, as quais nunca usei, por exemplo.)

A importância prática dessa pergunta é se eu incentivo os novos desenvolvedores a aprender Ant , ou se eles deveriam aprender algo mais para compilar?

Eu nunca estou muito informado sobre as tendências, por isso seria ótimo ouvir de outros desenvolvedores Java o que eles acham que é a melhor ferramenta de criação e o que eles acham que os novos desenvolvedores deveriam aprender.

— Sam Goldberg
fonte

Leia todas as respostas abaixo e todas foram ótimas! Obrigado pelas informações sobre as melhorias que o Maven oferece em relação ao Ant. Eu estarei olhando para Maven.

— Sam Goldberg

São poucos os projetos que são simples o suficiente para não exigir toneladas de scripts para o ant. O Maven lida com muitas dessas coisas de maneira padrão.

Ant é basicamente um script de shell em XML (e usando comandos Ant em vez de comandos de shell).

— user253751

Formiga é uma incrível perda de tempo. Mesmo quando Maven era terrível, era uma escolha mais inteligente. O Ant não tem como ser integrado a um IDE e os projetos Java são uma enorme bagunça de arquivos - você gasta 30% do seu tempo pulando de um arquivo para outro.

— Bryan hunt

@bryanhunt: acabamos usando o Maven para todos os novos projetos. No entanto, não encontrei uma maneira agradável de o Maven criar um pacote de implantação para aplicativos Java. (É bom para copiar dependências, fazer upload de jar.) A maioria das postagens que li sobre como fazê-lo, digamos, usa o plugin Ant. Então, eu acho que estou usando Ant para preparar a saída final do Maven. E parece muito mais fácil fazê-lo no Ant do que usar o plug-in Maven Assembly.

— Sam Goldberg

23

Eu concordo com outras pessoas aqui que o Maven parece ter assumido os projetos mais significativos que eu já observei.

Embora o Ant seja altamente flexível, o arquivo de construção não é padronizado; portanto, quando você muda para um novo projeto ou empresa, os destinos são nomeados de maneira diferente, o arquivo é estruturado de maneira diferente, as dependências entre destinos podem ou não ser estabelecidas, etc.

Com o Maven, você também recebe o benefício de não ter que carregar dependências binárias (estou falando de jarros) no sistema SCM. Muitas outras excelentes ferramentas Java sabem ler um arquivo POM do Maven (o benefício da padronização), para que ferramentas como IDEs possam configurar um projeto do Maven muito rapidamente, e construir ferramentas como o Jenkins podem executar facilmente as compilações do Maven.

— RonU
fonte

13

Devo acrescentar também que o uso do Maven torna nossos projetos independentes de IDE, e se você já esteve em uma loja que teve guerras de IDE, pode gostar de eliminar essa batalha religiosa!

— RonU

11

Eu tenho trabalhado com Ant e com Maven. Na minha experiência, Maven tem uma vantagem muito forte sobre Ant.

Todos os projetos que vi nos últimos 2 ou 3 anos parecem estar usando o maven. Cerca de três anos atrás, isso me fez pensar, porque as versões anteriores usadas (algo de 2.0) pareciam bastante confiáveis e com erros. Em algum momento, porém (2.1 ou 2.2 não me lembro), o maven se tornou confiável e, depois de algum tempo, mudei de idéia para o oposto. Agora, prefiro me surpreender ao ver alguém que prefere formiga a maven.

Em uma nota menos positiva sobre o maven, minha experiência com a documentação não foi tão boa até agora. Acho que vi um produto com documentação pior que a do maven, mas não me lembro qual deles (alguma biblioteca antiga de CSV iirc).

— mosquito
fonte

2

Não sei, eu achei o Maven Reference bastante decente. Não é perfeito e, de fato, existem cantos escuros e sem documentos, mas ainda assim o IMHO é significativamente melhor que a média.

— Péter Török

@ PéterTörök right Maven Reference também é meus primeiros socorros. De alguma forma, embora a maioria das coisas que me preocupa acabe nesses cantos escuros e sem documentos . Para ser mais preciso, acho esses cantos mais "sombrios" do que "não documentados" - quero dizer, sinto que o conhecimento existe, mas não decifro. Eu não sei, talvez eu seja azarado. Ou talvez idiota. Ou talvez os caras do Maven não tenham um escritor de tecnologia decente em sua gangue

— gnat

1

Por que você já viu um projeto de código aberto com um escritor tecnológico decente? ;-)

— Péter Török

@ PéterTörök tão verdadeiro! :) O luxo dos projetos populares de OSS é que existem muitos especialistas que "substituem" o escritor de documentos. Para mim, isso foi o caso com Maven - sempre houve algum guru em torno de quem eu poderia perguntar sobre coisas complicadas

— mosquito

3

Estamos usando o Maven há vários anos. Ele suporta scripts Ant (assim como o Ant suporta BeanShell), portanto, seu conhecimento sobre Ant ainda pode ser útil. O Maven é muito mais poderoso, mas possui alguns requisitos adicionais de infraestrutura (você desejará que um servidor Artifactory ou Nexus hospede suas construções, se você compartilhar componentes entre vários projetos). Também é bem diferente do Ant, então você não pode aproveitar muito do seu conhecimento existente.

— TMN
fonte

1

Eu acho que Ant por si só está morto na água; ter que especificar todas as suas dependências do caminho de classe manualmente (dependendo da configuração) é muito manual e muito passível a erros. Se o Ant for usado junto com uma ferramenta de gerenciamento de dependências, como o Ivy, ele retém seu poder e remove a necessidade de gerenciar manualmente suas dependências.

O outro problema com o Ant quando comparado ao Maven é a falta de padronização, que foi mencionada em outras respostas. Ao passar de projeto em projeto ou trabalho em emprego, uma das coisas mais irritantes que acho é ter que aprender o novo padrão para diferentes arquivos Ant. O objetivo de Maven de convenção sobre configuração significa que dois projetos diferentes terão uma estrutura muito semelhante, tornando a transição entre eles muito mais fácil do que com o Ant.

Se o Ant ainda é mainstream ou não, isso dependerá do ambiente de desenvolvimento em que você está trabalhando. Se o projeto estiver em uma empresa pequena ou em uma start-up, eu imaginaria que o Maven seria a escolha natural e o tempo pode ser gasto investir em infraestrutura, como um Artefato. No entanto, grandes empresas investiram muitos anos e muito dinheiro em sua infraestrutura Ant (configurações, arquivos de compilação globais etc.), o que significa que estarão menos interessados em se afastar de uma tecnologia na qual investiram tanto dinheiro.

— Richard
fonte

0

Maven está em ascensão há muitos anos, e agora preciso aprender. As coisas sempre estão mudando, e saber que Ant está perdendo sua posição não é uma coisa ruim.

O Maven só pode ser um bom começo por um curto período de tempo, mas se facilitar nosso trabalho, vale a pena investir tempo para aprender.

— Jon Shanks
fonte