Ant è ancora nel "mainstream" per le build Java?

Sono d'accordo con gli altri qui che Maven sembra aver preso in consegna i progetti più significativi che ho visto.

Mentre Ant è altamente flessibile, il file di costruzione non è standardizzato, quindi quando si passa a un nuovo progetto o azienda, le destinazioni vengono denominate in modo diverso, il file è strutturato in modo diverso, le dipendenze tra target possono o non possono essere stabilite , ecc.

Con Maven, hai anche il vantaggio di non dover portare le dipendenze binarie (sto parlando di vasi) nel tuo sistema SCM. Un sacco di altri grandi strumenti Java sanno come leggere un file Maven POM (il vantaggio della standardizzazione), quindi strumenti come IDE possono creare un progetto Maven molto rapidamente e creare strumenti come Jenkins possono facilmente eseguire build Maven.

Ho lavorato con Ant e con Maven. Nella mia esperienza, Maven ha un strong vantaggio molto rispetto a Ant.

• Tutti i progetti che ho visto negli ultimi 2 o 3 anni sembrano utilizzare Maven. Circa 3 anni fa questo mi ha fatto meravigliare perché le versioni di Maven utilizzate in quel momento (2.0. Qualcosa) sembravano abbastanza inaffidabili e buggy. Ad un certo punto però (2.1 o 2.2 non ricordo) Maven è diventato affidabile e dopo un po 'di tempo trascorso con esso ho cambiato idea. Ora, preferirei essere sorpreso nel vedere qualcuno che preferisce la formica a un esperto.

Su una nota meno positiva su Maven, la mia esperienza con la sua documentazione non è stata così grande finora. Penso di aver visto un prodotto con documentazione peggiore di quello di Maven, ma non riesco a ricordare quale (qualche antica libreria CSV di iirc).

Usiamo Maven da diversi anni. Supporta lo scripting Ant (proprio come Ant supporta BeanShell), quindi la tua conoscenza di Ant potrebbe essere ancora utile. Maven è molto più potente, ma ha alcuni requisiti di infrastruttura aggiuntivi (ti consigliamo un server Artifactory o Nexus per ospitare le tue build se condividi componenti tra più progetti). È anche molto diverso da Ant, quindi non puoi sfruttare molte delle tue conoscenze esistenti.

Penso che Ant da solo sia morto nell'acqua; dover specificare manualmente tutte le dipendenze del classpath (a seconda della configurazione) è troppo manuale e lontano da errori. Se Ant viene utilizzato insieme a uno strumento di gestione delle dipendenze, come Ivy, mantiene la sua potenza e rimuove la necessità di gestire manualmente le dipendenze.

L'altro problema con Ant rispetto a Maven è la mancanza di standardizzazione, che è stata menzionata in altre risposte. Quando si passa da un progetto all'altro o da un lavoro all'altro, una delle cose più fastidiose che trovo è dover imparare il nuovo standard per diversi file Ant. L'obiettivo di Maven della convenzione sulla configurazione significa che due diversi progetti avranno una struttura molto simile, rendendo la transizione tra loro molto più semplice che con Ant .

Per quanto riguarda se Ant è ancora mainstream o meno, dipenderà dall'ambiente di sviluppo in cui stai lavorando. Se il progetto è in una piccola azienda o in una start-up, immagino che Maven sarebbe la scelta naturale e il momento può essere preso per investire nell'infrastruttura, come un artefatto. Tuttavia, le grandi aziende avranno investito molti anni e molti soldi nella loro infrastruttura Ant (configurazioni, file di build globali, ecc.), Il che significa che saranno meno entusiasti di abbandonare una tecnologia in cui hanno investito così tanti soldi.

Maven è in crescita da molti anni e ora ho bisogno di impararlo. Le cose cambieranno sempre e sapere che Ant sta perdendo la sua posizione non è una brutta cosa.

Maven può essere solo per un breve periodo, ma se rende il nostro lavoro più semplice, vale la pena investire il tempo per imparare.