Ant è ancora nel "mainstream" per build Java?


14

Stiamo lentamente sostituendo i file di comandi batch (windows .bat) che stavano semplicemente mettendo a dura prova le classi compilate nell'IDE degli sviluppatori, con build di formiche più complete (ovvero ottenendo da CVS, compilazione pulita, jar, archivio, e-mail, ecc.)

Ho trascorso molto tempo a studiare (e a correggere i problemi) con Ant, quindi mi sento più a mio agio ad usarlo per queste attività. Ma mi chiedo se Ant sia ancora così ampiamente utilizzata come quando ho iniziato a studiare, o se "il mondo è passato" a qualcosa di più nuovo (e forse più intenso). (Ho iniziato a vedere distribuito più materiale di costruzione Maven, che non ho mai usato, per esempio.)

L'importanza pratica di questa domanda è se spingo i nuovi sviluppatori ad imparare Ant o se dovrebbero imparare qualcos'altro per le build?

Non sono mai troppo in cima alle tendenze, quindi sarebbe bello sentire da altri sviluppatori Java quale pensano che sia il miglior strumento di costruzione e cosa pensano che i nuovi sviluppatori dovrebbero imparare.


Leggi tutte le risposte qui sotto ed erano tutte fantastiche! Grazie per le intuizioni su quali miglioramenti Maven offre rispetto alla formica. Esaminerò Maven.
Sam Goldberg,

Sono pochissimi i progetti abbastanza semplici da non richiedere tonnellate di script per la formica. Maven gestisce molte di queste cose in modo standard.

Ant è fondamentalmente uno script di shell in XML (e usando i comandi Ant invece dei comandi di shell).
user253751

La formica è un'incredibile perdita di tempo. Anche quando la cottura era terribile, era una scelta più intelligente. Ant non ha modo di integrarsi in un IDE e i progetti Java sono un enorme casino di file: passi il 30% del tuo tempo a saltare da un file all'altro.
Bryan Hunt,

@bryanhunt: abbiamo finito per usare Maven per tutti i nuovi progetti. Tuttavia, non ho trovato un modo carino per Maven di creare un pacchetto di distribuzione per le app Java. (Va bene per copiare dipendenze, caricare jar.) La maggior parte dei post che leggo rispondono su come farlo, diciamo per usare il plugin Ant. Quindi trovo che sto usando Ant per governare l'output finale di Maven. E sembra molto più facile farlo in Ant piuttosto che usare il plugin Maven Assembly.
Sam Goldberg,

Risposte:


23

Sono d'accordo con altri qui sul fatto che Maven sembra aver assunto i progetti più significativi che ho visto.

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

Con Maven, ottieni anche il vantaggio di non dover portare dipendenze binarie (sto parlando di barattoli) nel tuo sistema SCM. Molti altri fantastici strumenti Java sanno leggere un file POM Maven (il vantaggio della standardizzazione), quindi strumenti come gli IDE possono impostare un progetto Maven molto rapidamente e strumenti di costruzione come Jenkins possono facilmente eseguire build Maven.


13
Vorrei anche aggiungere che l'uso di Maven rende i nostri progetti IDE-agnostici, e se sei mai stato in un negozio con guerre IDE, puoi apprezzare l'eliminazione di questa battaglia religiosa!
RonU,

11

Ho lavorato con Ant e con Maven. Nella mia esperienza, Maven ha un vantaggio molto forte rispetto alla formica.

  • Tutti i progetti che ho visto negli ultimi 2 o 3 anni sembrano usare Maven. Circa 3 anni fa questo mi ha fatto meravigliare perché le versioni usate in precedenza (2.0.something) sembravano essere inaffidabili e buggy. Ad un certo punto (2.1 o 2.2, non ricordo) Maven è diventato affidabile e dopo un po 'di tempo trascorso con esso ho cambiato idea in contrario. Ora, preferirei essere sorpreso nel vedere qualcuno che preferisce la formica al forno.

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


2
Non so, ho trovato il Maven Reference abbastanza decente. Non è perfetto, e ci sono davvero angoli scuri privi di documenti, ma IMHO è significativamente migliore della media.
Péter Török,

@ PéterTörök giusto Maven Reference è anche il mio primo soccorso. In qualche modo sebbene la maggior parte delle cose che mi preoccupano finisca in questi angoli bui e privi di documenti . Per essere precisi, trovo questi angoli più "oscuri" che "non documentati" - voglio dire, sento che la conoscenza è lì ma non riesco a decifrarla. Forse non sono sfortunato. O forse stupido. O forse ai ragazzi di Maven manca solo uno scrittore di tecnologia decente nella loro banda
moscerino del

1
Perché, hai mai visto un progetto open source che ha avuto un discreto scrittore tecnologico? ;-)
Péter Török,

@ PéterTörök così vero! :) Il lusso dei popolari progetti OSS è che ci sono molti ragazzi esperti che "sostituiscono" il doc writer. Per me è stato il caso di Maven - ci sono sempre stati dei guru attorno ai quali avrei potuto chiedere cose difficili
moscerino del

3

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


1

Penso che Ant da solo sia morto nell'acqua; dover specificare manualmente tutte le dipendenze del percorso di classe (a seconda della configurazione) è troppo manuale e soggetto a 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 è imparare il nuovo standard per diversi file Ant. L'obiettivo di Maven di convenire sulla configurazione significa che due diversi progetti avranno una struttura molto simile, rendendo la transizione tra loro molto più semplice rispetto a Ant.

Per quanto riguarda se Ant è ancora mainstream o no, 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 che il tempo può essere impiegato investire nell'infrastruttura, come un manufatto. 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ì tanto denaro.


0

Maven è in aumento 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 potrebbe essere il migliore e solo per un breve periodo, ma se facilita il nostro lavoro, vale la pena investire il tempo per imparare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.