Perché usare Gradle invece di Ant o Maven? [chiuso]

Cosa mi dà davvero un altro strumento di build destinato a Java?

Se usi Gradle su un altro strumento, perché?

Io stesso non uso Gradle nella rabbia (solo un progetto giocattolo finora) [autore significa che finora hanno utilizzato Gradle solo su un progetto giocattolo, non che Gradle sia un progetto giocattolo - vedi commenti] , ma direi che i motivi che uno prenderebbe in considerazione per usarlo sarebbe a causa delle frustrazioni di Ant e Maven.

Nella mia esperienza Ant è spesso di sola scrittura (sì, lo so che è possibile scrivere costruzioni meravigliosamente modulari ed eleganti , ma il fatto è che molte persone non lo fanno). Per qualsiasi progetto non banale diventa strabiliante e si prende molta cura per garantire che le build complesse siano veramente portatili. La sua natura imperativa può portare alla replica della configurazione tra build (anche se le macro possono aiutare qui).

Maven adotta l'approccio opposto e si aspetta che ti integri completamente con il ciclo di vita di Maven. Gli utenti esperti di formiche lo trovano particolarmente sconcertante poiché Maven rimuove molte delle libertà che hai in Ant. Ad esempio c'è un blog Sonatype che elenca molte delle critiche Maven e le loro risposte.

Il meccanismo del plug-in Maven consente configurazioni di build molto potenti e il modello di ereditarietà consente di definire un piccolo set di POM principali che incapsulano le configurazioni di build per l'intera azienda e che i singoli progetti possono ereditare tali configurazioni, lasciandole leggere. La configurazione di Maven è molto dettagliata (anche se Maven 3 promette di risolverlo), e se vuoi fare qualcosa che "non è il modo Maven" devi scrivere un plugin o usare l'integrazione di hacky Ant. Nota Mi piace scrivere plugin Maven ma apprezzo che molti si opporranno allo sforzo in questione.

Gradle promette di colpire il punto debole tra Ant e Maven. Usa l'approccio di Ivy per la risoluzione delle dipendenze. Consente la convenzione sulla configurazione, ma include anche attività di formica come cittadini di prima classe. Inoltre, consente saggiamente di utilizzare i repository Maven / Ivy esistenti.

Quindi, se hai colpito e bloccato con uno qualsiasi dei punti dolenti di Ant / Maven, probabilmente vale la pena provare Gradle, anche se secondo me resta da vedere se non scambieresti problemi noti con altri sconosciuti. La prova del budino sta nel mangiare, quindi mi riservo di giudicare fino a quando il prodotto non è un po 'più maturo e altri hanno appianato eventuali nodi (lo chiamano bordo sanguinante per un motivo). Lo userò comunque nei miei progetti di giocattoli, è sempre bene essere consapevoli delle opzioni.

Gradle può essere usato per molti scopi - è un coltellino svizzero molto migliore di Ant - ma è specificamente focalizzato su build multi-progetto.

Prima di tutto, Gradle è uno strumento di programmazione delle dipendenze che significa anche che è uno strumento di programmazione. Con Gradle puoi eseguire qualsiasi attività casuale nella tua configurazione e Gradle assicurerà che tutte le dipendenze dichiarate siano eseguite correttamente e tempestivamente. Il codice può essere distribuito su più directory in qualsiasi tipo di layout (albero, piatto, sparso, ...).

Gradle ha due fasi distinte: valutazione ed esecuzione. Fondamentalmente, durante la valutazione Gradle cercherà e valuterà gli script di compilazione nelle directory che dovrebbe cercare. Durante l'esecuzione Gradle eseguirà le attività che sono state caricate durante la valutazione tenendo conto delle interdipendenze delle attività.

Oltre a queste funzionalità di programmazione delle dipendenze, Gradle aggiunge funzionalità di dipendenza di progetti e JAR mediante l'integrazione con Apache Ivy. Come sapete, Ivy è uno strumento di gestione delle dipendenze molto più potente e molto meno ponderato di quanto affermi Maven.

Gradle rileva dipendenze tra progetti e tra progetti e JAR. Gradle funziona con repository Maven (download e upload) come quello di iBiblio o dei propri repository, ma supporta anche e altri tipi di infrastruttura di repository che potresti avere.

In build multiprogetto Gradle è sia adattabile che si adatta alla struttura e all'architettura della build. Non devi adattare la tua struttura o architettura al tuo strumento di costruzione come sarebbe richiesto con Maven.

Gradle fa di tutto per non ostacolarti, uno sforzo che Maven non fa quasi mai. La convenzione è buona ma lo è anche la flessibilità. Gradle offre molte più funzioni rispetto a Maven, ma soprattutto in molti casi Gradle ti offrirà un percorso di transizione indolore lontano da Maven.

Questo può essere un po 'controverso, ma Gradle non nasconde il fatto che si tratta di un linguaggio di programmazione completo.

Ant + ant-contrib è essenzialmente un linguaggio di programmazione completo e turing in cui nessuno vuole davvero programmare.

Maven cerca di adottare l'approccio opposto, cercando di essere completamente dichiarativo e costringendoti a scrivere e compilare un plugin se hai bisogno di logica. Impone anche un modello di progetto che è completamente inflessibile. Gradle unisce il meglio di tutti questi strumenti:

• Segue la convenzione di over-configuration (ala Maven) ma solo nella misura desiderata
• Ti consente di scrivere attività personalizzate flessibili come in Ant
• Fornisce supporto per progetti multi-modulo superiore a Ant e Maven
• Ha un DSL che semplifica l'80% delle cose e il 20% delle cose (a differenza di altri strumenti di costruzione che rendono l'80% facile, il 10% possibile e il 10% effettivamente impossibile).

Gradle è lo strumento di costruzione più configurabile e flessibile che devo ancora usare. Richiede alcuni investimenti per apprendere il DSL e concetti come le configurazioni, ma se hai bisogno di uno strumento di compilazione JVM senza fronzoli e completamente configurabile è difficile da battere.

Gradle combina perfettamente sia Ant che Maven, prendendo il meglio da entrambi i framework. Flessibilità da Ant e convenzione su configurazione, gestione delle dipendenze e plugin di Maven.

Quindi, se si desidera avere una build java standard, come in maven, ma l'attività di test deve eseguire alcuni passaggi personalizzati, potrebbe apparire come di seguito.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

Inoltre utilizza una sintassi groovy che dà molto più potere espressivo rispetto all'xml di ant / maven.

È un superset di Ant: puoi usare tutti i compiti di Ant in gradle con una sintassi più gradevole e groovy, ad es.

ant.copy(file:'a.txt', toDir:"xyz")

o

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

Usiamo Gradle e l'abbiamo scelto tra Maven e Ant. Ant ci ha dato la massima flessibilità e Ivy offre una migliore gestione delle dipendenze rispetto a Maven, ma non c'è un grande supporto per le build multi-progetto. Si finisce per fare un sacco di codice per supportare build multi-progetto. Anche avere alcuni build-by-convention è bello e rende gli script di build più concisi. Con Maven, ci vuole un build troppo lontano per convenzione e la personalizzazione del processo di generazione diventa un hack. Inoltre, Maven promuove ogni progetto che pubblica un artefatto. A volte hai un progetto suddiviso in sottoprogetti ma vuoi che tutti i sottoprogetti vengano creati e sottoposti a versione insieme. Non proprio qualcosa per cui Maven è progettato.

Con Gradle puoi avere la flessibilità di Ant e costruire per convenzione di Maven. Ad esempio, è banale estendere il ciclo di vita della build convenzionale con le proprie attività. E non sei costretto a usare una convenzione se non vuoi. Groovy è molto più carino da programmare rispetto a XML. In Gradle, è possibile definire dipendenze tra progetti sul file system locale senza la necessità di pubblicare artefatti per ciascuno in un repository. Infine, Gradle utilizza Ivy, quindi ha un'eccellente gestione delle dipendenze. L'unico aspetto negativo per me finora è la mancanza di una integrazione di Eclipse, ma le opzioni per Maven non sono molto migliori.

Questa non è la mia risposta, ma sicuramente risuona con me. È dal radar tecnologico di ThoughtWorks dell'ottobre 2012 :

Due cose hanno causato affaticamento con strumenti di costruzione basati su XML come Ant e Maven: troppe parentesi graffe arrabbiate e la ruvidezza delle architetture plug-in. Mentre i problemi di sintassi possono essere gestiti attraverso la generazione, le architetture di plug-in limitano fortemente la capacità degli strumenti di costruzione di crescere con grazia man mano che i progetti diventano più complessi. Abbiamo capito che i plug-in hanno il livello sbagliato di astrazione e preferiamo invece strumenti basati sul linguaggio come Gradle e Rake, perché offrono astrazioni più precise e maggiore flessibilità a lungo termine.

Gradle riporta il divertimento nel software di costruzione / assemblaggio. Ho usato la formica per costruire software per tutta la mia carriera e ho sempre considerato l'attuale parte "buildit" del lavoro di sviluppo un male necessario. Qualche mese fa la nostra azienda si stancò di non usare un repository binario (ovvero il check-in dei vasetti nel vcs) e mi fu affidato il compito di indagare su questo. Iniziato con l'edera poiché poteva essere imbullonato sulla formica, non ha avuto molta fortuna a pubblicare i miei manufatti costruiti come volevo. Ho cercato Maven e l'hackato con xml, ha funzionato magnificamente per alcune semplici librerie di aiuto, ma ho riscontrato seri problemi nel tentativo di raggruppare le applicazioni pronte per la distribuzione. Ho avuto un po 'di tempo a cercare plug-in su Google e a leggere forum e ho finito col scaricare trilioni di barattoli di supporto per vari plug-in che ho avuto difficoltà a usare.

Ma dal primo giorno il mio umore ha iniziato a migliorare. Stavo arrivando da qualche parte. Mi ci vollero due ore per migrare il mio primo modulo di formica e il file di compilazione era praticamente nulla. Facilmente montabile su uno schermo. Il grande "wow" era: costruire script in XML, quanto è stupido? il fatto che dichiarare una dipendenza richieda UNA riga è molto interessante per me -> puoi facilmente vedere tutte le dipendenze per un determinato progetto su una pagina. Da allora in poi sono stato su un piano costante, per ogni problema che ho affrontato finora c'è una soluzione semplice ed elegante. Penso che questi siano i motivi:

• groovy è molto intuitivo per gli sviluppatori Java
• la documentazione è fantastica o eccezionale
• la flessibilità è infinita

Ora passo i miei giorni a cercare nuove funzionalità da aggiungere al nostro processo di creazione. Quanto è malato?

È anche molto più semplice gestire le build native. Ant e Maven sono effettivamente solo Java. Esistono alcuni plugin per Maven che cercano di gestire alcuni progetti nativi, ma non svolgono un lavoro efficace. È possibile scrivere attività formiche che compilano progetti nativi, ma sono troppo complesse e scomode.

Facciamo Java con JNI e molti altri bit nativi. Gradle ha notevolmente semplificato il nostro pasticcio di formiche. Quando abbiamo iniziato a introdurre la gestione delle dipendenze nei progetti nativi, era disordinato. Abbiamo avuto Maven per farlo, ma il codice Gradle equivalente era una piccola frazione di ciò che era necessario in Maven, e la gente poteva leggerlo e capirlo senza diventare guru Maven.

Sono in parte d'accordo con Ed Staub. La pendenza è sicuramente più potente rispetto alla maven e offre maggiore flessibilità a lungo termine.

Dopo aver eseguito una valutazione per passare da Maven a Gradle, abbiamo deciso di attenerci al Maven stesso per due problemi che abbiamo riscontrato con Gradle (la velocità è più lenta di Maven, il proxy non funzionava).