Perché Maven ha una cattiva reputazione? [chiuso]


99

Si parla molto su Internet di quanto Maven sia cattivo. Uso alcune funzionalità di Maven da alcuni anni e il vantaggio più importante a mio avviso è la gestione delle dipendenze.

La documentazione di Maven è meno che adeguata, ma generalmente quando ho bisogno di realizzare qualcosa lo capisco una volta e poi funziona (ad esempio quando ho implementato la firma dei vasi). Non penso che Maven sia eccezionale, ma risolve alcuni problemi che senza di esso sarebbero un vero dolore.

Allora, perché Maven ha una cattiva reputazione e quali problemi con Maven posso aspettarmi in futuro? Forse ci sono alternative molto migliori che non conosco? (Ad esempio, non ho mai guardato Ivy in dettaglio.)

NOTA: questo non è un tentativo di causare un argomento. È un tentativo di cancellare il FUD.


29
Non ho mai sentito nessuno parlare male di Maven. Ho scoperto che i progetti sono molto più produttivi con Maven che con Ant.
Taylor Leese

2
Sono d'accordo con Taylor. Non ho usato Maven, ma ho sentito molte persone parlarne molto bene. Questa domanda assomiglia molto a FUD.
Matthew Flaschen

27
@Taylor, @Matthew, @victor: sono sorpreso che tu non abbia visto alcune delle invettive di Maven. È uno strumento molto divisivo. È una vera cosa che si ama o si odia. Alcune persone amano l'intelligenza della gestione delle dipendenze e accusano coloro a cui non piace di non ottenerla, e alcune persone vedono solo i problemi che possono e si verificano con dipendenze distribuite complesse e decidono che non ne vale la pena.
Dan Dyer

8
Maven non rispetta il principio KISS. Prova a fare qualsiasi cosa oltre a mvn clean install e sei nei guai. Con Ant puoi fare quello che vuoi senza dolore.
TraderJoeChicago

4
È solo un aneddoto, ma il passaggio da Maven ad Ant ha fatto sì che i nostri tempi di costruzione incrementali passassero da ~ 15 secondi a oltre 2 minuti. Non troverai molti fan di Maven nella nostra squadra.
Peter Bratton

Risposte:


141

Ho esaminato Maven circa sei mesi fa. Stavamo iniziando un nuovo progetto e non avevamo alcuna eredità da supportare. Detto ciò:

  • Maven è tutto o niente. O almeno per quanto ho potuto capire dalla documentazione. Non puoi usare facilmente Maven come sostituto immediato di Ant e adottare gradualmente funzionalità più avanzate.
  • Secondo la documentazione, Maven è la felicità trascendentale che realizza tutti i tuoi sogni più sfrenati. Devi solo meditare sul manuale per 10 anni prima di diventare illuminato.
  • Maven rende il processo di compilazione dipendente dalla connessione di rete.
  • Maven ha messaggi di errore inutili. Confronta "Target x non esiste nel progetto y" di formica con "Attività non valida" run ": devi specificare una fase del ciclo di vita valida o un obiettivo nel formato plugin: goal o pluginGroupId: pluginArtifactId: pluginVersion: goal" Utilmente, suggerisce di eseguire mvn con -e per ulteriori informazioni, il che significa che stamperà lo stesso messaggio, quindi un'analisi dello stack per BuildFailureException.

Gran parte della mia avversione per Maven può essere spiegata dal seguente estratto da Better Builds with Maven:

Quando qualcuno vuole sapere cos'è Maven, di solito chiede "Cos'è esattamente Maven?", E si aspetta una risposta breve e concisa. "Beh, è ​​uno strumento di compilazione o un framework di scripting" Maven è più di tre parole noiose e poco interessanti. È una combinazione di idee, standard e software, ed è impossibile distillare la definizione di Maven in morsi sonori semplicemente digeriti. Le idee rivoluzionarie sono spesso difficili da trasmettere con le parole.

Il mio consiglio: se non riesci a trasmettere le idee con le parole, non dovresti tentare di scrivere un libro sull'argomento, perché non ho intenzione di assorbire telepaticamente le idee.


134
Per coloro che capiscono Maven, non è necessaria alcuna spiegazione. Per coloro che non lo fanno, nessuna spiegazione è possibile.
Apocalisp

35
Uno dei tuoi punti elenco è falso. -o - modalità offline, quindi no, non rende il processo di compilazione dipendente dalla connessione di rete.
MetroidFan2002

10
Sono d'accordo sul punto tutto o niente. Ho visto molte persone sprecare troppo tempo cercando di mantenere metà del loro portafoglio di progetti in formica e metà in Maven. Una volta che ti impegni, devi impegnarti per convertire ogni parte della tua distribuzione.
sal

14
@ Apocalisp: Quindi, in altre parole, le uniche persone che capiscono Maven sono le persone che lo hanno scritto?
Powerlord

5
Maven è tutto o niente. Non è vero. Puoi usare Maven per la gestione delle dipendenze e nient'altro se lo desideri. Tutto ciò che serve è un esempio funzionante di come utilizzare le attività di Maven ant per leggere il file pom e generare un classpath ANT contenente tutte le dipendenze.
Jherico

109
  • Ti impone una struttura rigida sin dall'inizio.
  • È basato su XML, quindi è difficile da leggere come lo era ANT.
  • La sua segnalazione degli errori è oscura e ti lascia bloccato quando le cose vanno male.
  • La documentazione è scarsa.
  • Rende le cose difficili facili e le cose semplici difficili.
  • Ci vuole troppo tempo per mantenere un ambiente di build Maven, che sconfigge il punto di avere un sistema di build onnicomprensivo.
  • Ci vuole molto tempo per capire che hai trovato un bug in Maven e non hai configurato qualcosa di sbagliato. E gli insetti esistono e in posti sorprendenti.
  • Promette molto ma ti tradisce come un amante bello e seducente ma emotivamente freddo e manipolatore.

45
++ Rende le cose difficili facili e le cose semplici difficili. È così giusto!
Martin K.

8
"Promette molto ma ti tradisce come un amante bello e seducente ma emotivamente freddo e manipolatore." hahahaha ... suona molto come quel fong da maestro di "Balls of Fury"
cesar

8
Punto 2: usa quasi sempre gli elementi, quasi mai gli attributi, quindi l'XML è ancora più difficile da leggere di quello di Ant!
Carl Smotricz

4
+1 per l'ultimo proiettile. Niente rende la mia giornata come imbattersi in un'analogia fantastica e divertente che è così vera.
Adam,

1
La documentazione non è scarsa, è ottima.
HDave

96

Ho sicuramente lamentato e lamentato in passato Maven . Ma ora, non sarei senza di essa. Ritengo che i benefici superino di gran lunga qualsiasi problema. Principalmente:

  • Struttura del progetto standardizzata.
    • Dato un nuovo sviluppatore che si unisce a un progetto:
      • Quando dici che si tratta di un progetto Maven, lo sviluppatore conosce il layout del progetto e come creare e impacchettare il progetto
      • Quando dici che è un progetto Ant, lo sviluppatore dovrà aspettare che tu spieghi di più o dovrà passare attraverso build.xml per capire le cose.
    • Certo, è sempre possibile imporre uno standard a livello aziendale con Ant, ma penso che il più delle volte reinventerai la proverbiale ruota.
  • Gestione delle dipendenze.
    • Non solo con librerie esterne ma anche con librerie / moduli interni. Assicurati di utilizzare un server proxy del repository Maven come Nexus o Artifactory .
    • È possibile fare alcune di queste cose con Ivy . In effetti, se tutto ciò di cui hai bisogno è una gestione delle dipendenze, probabilmente stai meglio usando Ivy.
  • Soprattutto all'interno di un progetto. Ho trovato abbastanza utile suddividere piccoli sottoprogetti e Maven lo gestisce bene. È molto più difficile con la formica.
  • Gestione degli artefatti standardizzata (specialmente in combinazione con nexus o artifactory )
  • Il plug-in di rilascio è meraviglioso.
  • L'integrazione di Eclipse e NetBeans è abbastanza buona.
  • L'integrazione con Hudson è eccezionale. In particolare i grafici di tendenza per cose come findbugs.
  • È un punto minore, ma il fatto che Maven incorpori dettagli come il numero di versione all'interno del barattolo o di war (non solo nel nome del file) per impostazione predefinita è estremamente utile.

Gli svantaggi per me sono principalmente:

  • La riga di comando è abbastanza inutile. Questo mi ha scoraggiato molto all'inizio.
  • Il formato XML è molto dettagliato. Posso capire perché è stato fatto in quel modo, ma è ancora un dolore da leggere.
    • Detto questo, ha un XSD per un facile editing in un IDE.
  • All'inizio è difficile capirlo. Cose come il ciclo di vita, per esempio.

Credo davvero che valga la pena dedicare un po 'di tempo a conoscere Maven.


2
Non mi interessa particolarmente il formato XML (Eclipse può occuparsi della maggior parte delle parti noiose) e le istruzioni di compilazione per progetti di grandi dimensioni sono in genere sgradevoli e complesse comunque. Ad esempio, non hai veramente sbattuto la testa su un muro di mattoni fino a quando non hai provato a convincere GNU automake a fare qualcosa che non gli interessa ...
Donal Fellows

2
IntelliJ ha anche un eccellente supporto Maven.
Steven Benitez

1
Oh guarda una risposta sensata con i dettagli.
Tim O'Brien

80

La mia esperienza pratica da due grandi progetti è che abbiamo speso 1000-1500 ore per ogni progetto su problemi relativi a Maven, escludendo uno sforzo di 500 ore per passare da Maven 1 a Maven 2.

Da allora, devo dire che odio assolutamente Maven. Mi sento frustrato quando ci penso.

L'integrazione di Eclipse è orribile. (Abbiamo avuto infiniti problemi con la generazione del codice, ad esempio, dove eclipse è uscito sincronizzato con il codice generato e ha richiesto una ricostruzione completa, abbastanza spesso. La colpa è sia di maven che di eclipse, ma eclipse è più utile di maven e dice emacs, quindi l'eclissi rimane e Maven deve andarsene.)

Avevamo molte dipendenze e, come abbiamo scoperto, gli errori di sintassi vengono effettivamente commessi su repository esperti pubblici abbastanza spesso, il che può rovinare ore del tuo tempo prezioso. Ogni settimana. La soluzione alternativa è avere un proxy o un repository governato localmente e anche questo ha richiesto un po 'di tempo.

La struttura del progetto Mavens non è realmente adatta per lo sviluppo con Eclipse e il tempo di compilazione in eclipse aumenta.

Un effetto della generazione del codice e del problema di sincronizzazione, abbiamo dovuto ricostruire da scrach piuttosto spesso, riducendo il ciclo di codice / compilazione / test a un ciclo infinito di compilazione / navigazione web / sleep / die / codice, riportandoti indietro agli anni '90 e Tempi di compilazione di 40 minuti.

L'unica scusa per Maven è la risoluzione delle dipendenze, ma mi piacerebbe farlo di tanto in tanto, non in ogni build.

Per riassumere, Maven è il più lontano possibile dai KISS. Inoltre, i sostenitori tendono ad essere il tipo di persone che festeggiano in più il giorno del loro compleanno quando la loro età è un numero primo. Sentiti libero di votarmi contro :-)


3
Sono d'accordo con alcune di quelle che dici in realtà, anche se penso di aver finalmente capito bene. Per ottenere quello che vuoi però puoi dare un'occhiata a Ivy, non l'ho ancora provato ma sembra portare la gestione delle dipendenze in un ambiente Ant più strutturato.
Newtopian

5
Quindi, hai trovato una buona alternativa a Maven?
Thilo

4
L'integrazione di Eclipse è ancora orribile. Nonostante i plug-in aggiornati, ci sono attività maven controllate da plug-in che falliscono con oscuri messaggi di errore. I colleghi poi mi dicono di passare a una shell dei comandi ed eseguire lo stesso comando ... poi funziona misteriosamente. Eclipse è un ambiente maturo, il plugin Maven è molto indietro.
Carl Smotricz

2
C'è una differenza fondamentale nel modo in cui Maven ed Eclipse definiscono cos'è un progetto. In Maven, un progetto è più o meno un modo conveniente per organizzare il codice sorgente. Eclipse è stato inizialmente progettato in modo da poter lavorare su uno o più progetti più o meno indipendenti contemporaneamente. Requisiti successivi (non sempre validi) portarono all'abuso dei progetti da parte di IBM come "moduli" che eclipse effettivamente gestisce piuttosto male. Per far convergere le definizioni, in molti casi, i progetti maven dovrebbero probabilmente essere mappati nelle cartelle dei sorgenti di eclipse. Tuttavia, poiché Maven fa schifo, perché preoccuparsi.
KarlP

3
Hey! Mi lamento del fatto che la prossima volta che sarò un'età primaria è 29, e la prossima età del cubo perfetto è 64, e la mia ultima età del penteratto perfetto sarà 32 ... ma non sostengo attivamente Maven.
cwallenpoole

46

Maven è fantastico. Il motivo della sua reputazione ha a che fare con la ripida curva di apprendimento, secondo me. (che sono finalmente vicino a superare)

La documentazione è un po 'approssimativa da leggere, semplicemente perché sembra che ci sia molto testo e nuove cose da comprendere prima che abbia un senso. Dico che il tempo è tutto ciò che serve perché Maven sia più ampiamente elogiato.


6
Questo può essere in qualche modo vero, ma ho scoperto che l'utilizzo dell'integrazione di Maven con Eclipse aiuta davvero a ridurre la curva di apprendimento per le persone. m2eclipse.codehaus.org
Taylor Leese

2
@Taylor, ho avuto molti problemi con il plug-in, specialmente se usi qualche altra versione di Eclipse o il paradiso non vuole RAD. Penso che ci stia arrivando, comunque ...
Dan

L'ho usato solo con Eclipse 3.3, 3.4 e lo studio di sviluppo JBoss e ho concordato che ci sono alcuni piccoli fastidi (come l'editor POM che non funziona bene) ma non ho avuto grossi problemi.
Taylor Leese

10
Non è la curva di apprendimento che mi dà fastidio. Non è davvero così difficile da capire. Il mio problema è che per grandi progetti (commerciali) si ottiene molto meno valore dell'impegno speso. OK, i tuoi progetti si sviluppano. Fantastico, ma il costo di un anno uomo speso, costanti fallimenti di costruzione dovuti a fattori esterni, 10 minuti di compilazioni invece di 5 secondi e un brutto spazio di lavoro di eclissi, semplicemente non ne vale la pena. Inoltre, allo stesso costo, puoi più o meno assumere un ragazzo che costruisce costantemente il baule manualmente.
KarlP

8
@Karlp - beh, non lo capisci ancora completamente ... 1.) "errori dovuti a fattori esterni" - dovresti creare un repository del progetto in cui tieni tutte le tue dipendenze e di cui controlli le versioni. 2.) "10 minuti di compilazione invece di 5 secondi" - forse per l'installazione iniziale di maven e la prima build - maven scarica tutte le dipendenze di cui ha bisogno più il tuo progetto - ma le build regolari che stai facendo per tentare di costruire il tuo codice non dovrebbero essere in download - vedere 1 - anche, modalità offline. 3.) "ugly eclipse workspace": maven funziona in tutti i principali IDE (NB, IntelliJ) e dalla riga di comando.
Nate

24

Perché Maven è un dispositivo per ridurre gli uomini adulti a masse singhiozzanti di assoluto terrore.


3
Dovremmo produrlo in serie e venderlo a tutti i cattivi per un enorme profitto!
Joachim Sauer

7
No! Maven non può essere utilizzato a scopo di lucro. Può essere usato solo per il male.
Apocalisp

18

Professionisti:

  • Gestione delle dipendenze. Già da diversi anni io e i miei colleghi non scarichiamo e gestiamo manualmente le dipendenze. Questo è un enorme risparmio di tempo.
  • IDE-indipendenza. Risulta che tutti i principali IDE, Eclipse, IDEA e NetBeans hanno un supporto decente per i progetti Maven in modo che i nostri sviluppatori non siano bloccati in un IDE particolare.
  • Riga di comando. Con Maven, il supporto di configurazioni IDE e da riga di comando simultanee è semplice, il che è utile per l'integrazione continua.

Contro:

Concorrenza:

  • Ant: non ha la gestione delle dipendenze. Periodo.
  • Ivy: ancora meno matura di Maven (non che anche quest'ultimo non abbia le sue stranezze). Quasi lo stesso set di funzionalità, quindi nessun motivo valido per spostarsi. Ho fatto diversi tentativi per provarlo; tutto senza successo.

Conclusione: tutti i nostri progetti vengono realizzati con Maven già da diversi anni.


3
Ant non compete con Maven. Ivy non compete con Maven (compete con i compiti di Maven Ant). Maven è più di uno strumento di compilazione + gestione delle dipendenze. Periodo.
Pascal Thivent

18

Penso che abbia una cattiva reputazione con persone che hanno i progetti più semplici e più complicati.

Se stai costruendo un singolo WAR da una singola base di codice, ti costringe a spostare la struttura del tuo progetto e ad elencare manualmente i due dei tre vasi nel file POM.

Se stai costruendo un EAR da un set di nove prototipi di file EAR con una combinazione di cinque file WAR, tre EJB e altri 17 strumenti, jar di dipendenza e configurazioni che richiedono di modificare MANIFEST.MF e file XML nelle risorse esistenti durante la compilazione finale; allora Maven è probabilmente troppo restrittivo. Un tale progetto diventa un pasticcio di complicati profili annidati, file di proprietà e uso improprio degli obiettivi di compilazione Maven e della designazione del classificatore.

Quindi, se ti trovi nel 10% inferiore della curva di complessità, è eccessivo. Nel 10% superiore di quella curva, sei in una camicia di forza.

La crescita di Maven è dovuta al fatto che funziona bene per l'80% medio


16

La mia esperienza fa eco alla frustrazione di molti dei post qui. Il problema con Maven è che avvolge e nasconde i dettagli della gestione della build nella sua ricerca della massima bontà automagica. Questo ti rende quasi indifeso se si rompe.

La mia esperienza è che qualsiasi problema con Maven è rapidamente degenerato in una caccia al beccaccino di più ore attraverso reti di file xml nidificati, in un'esperienza simile al canale radicolare.

Ho anche lavorato in negozi che facevano molto affidamento su Maven, le persone a cui piaceva (a cui piaceva per l'aspetto "premi un pulsante, fai tutto") non lo capivano. Le build di Maven avevano un milione di bersagli automatici, il che sono sicuro sarebbe utile se avessi avuto voglia di dedicare ore a leggere quello che hanno fatto. Meglio 2 obiettivi che funzionano che comprendi appieno.

avvertimento: ha lavorato l'ultima volta con Maven 2 anni fa, potrebbe essere migliore ora.


14

Come Glenn, non penso che Maven abbia una cattiva reputazione, ma una reputazione mista. Ho lavorato per 6 mesi esclusivamente cercando di migrare un progetto piuttosto grande su Maven e mostra chiaramente i limiti dello strumento.

Nella mia esperienza, Maven è buono per:

  • gestione delle dipendenze esterne
  • gestione centralizzata della build (eredità pom)
  • molti plugin per molte cose
  • ottima integrazione con strumenti di integrazione continua
  • ottime capacità di reporting (FindBugs, PMD, Checkstyle, Javadoc, ...)

E ha alcuni problemi con:

  • approccio tutto o niente (difficile migrare lentamente a Maven)
  • dipendenze complesse, dipendenze intermoduli
  • dipendenze cicliche (lo so, cattivo design, ma non possiamo aggiustare 5 anni di sviluppo ...)
  • coerenza (gli intervalli di versioni non funzionano allo stesso modo ovunque)
  • bug (di nuovo con gli intervalli di versione)
  • build riproducibili (a meno che non aggiusti il ​​numero di versioni di tutti i plugin, non puoi essere sicuro di ottenere la stessa build in 6 mesi)
  • mancanza di documentazione (il documento è abbastanza buono per le basi, ma non ci sono molti esempi su come gestire grandi progetti)

Per dare un po 'di contesto, ci sono circa 30 sviluppatori che lavorano su questo progetto, e il progetto è in circolazione da più di 5 anni, quindi: molta eredità, molti processi già in atto, molti strumenti proprietari personalizzati già in atto. Abbiamo deciso di provare a migrare a Maven perché il costo di manutenzione dei nostri strumenti proprietari stava diventando troppo alto.


12

Vorrei contrastare alcuni dei reclami presentati in questo forum:

Maven è tutto o niente. O almeno per quanto ho potuto capire dalla documentazione. Non puoi usare facilmente Maven come sostituto immediato di Ant e adottare gradualmente funzionalità più avanzate.

Non è vero. La grande vittoria di Maven è usarlo per gestire le tue dipendenze in modo razionale e se vuoi farlo in Maven e fare tutto il resto in Ant, puoi farlo. Ecco come:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Ora hai un oggetto classpath denominato "maven.classpath" che contiene tutte le dipendenze maven definite nel file pom. Tutto ciò di cui hai bisogno è mettere il jar dei task di maven ant nella directory lib di ant.

Maven rende il processo di compilazione dipendente dalla connessione di rete.

La dipendenza predefinita e il processo di recupero dei plug-in dipendono da una connessione di rete, sì, ma solo per la build iniziale (o se si modificano le dipendenze o i plug-in in uso). Dopodiché tutti i barattoli vengono memorizzati nella cache locale. E se vuoi forzare la connessione senza rete, puoi dire a Maven di utilizzare la modalità offline.

Ti impone una struttura rigida sin dall'inizio.

Non è chiaro se questo si riferisca al formato del file o al problema di "convenzione contro configurazione". Per quest'ultimo, ci sono molti valori predefiniti invisibili come la posizione prevista dei file e delle risorse di origine java o la compatibilità dell'origine. Ma questa non è rigidità, è l'inserimento di valori predefiniti ragionevoli per te in modo da non doverli definire esplicitamente. Tutte le impostazioni possono essere sovrascritte abbastanza facilmente (anche se per un principiante può essere difficile trovare nella documentazione come cambiare certe cose).

Se stai parlando del formato del file, beh, questo è coperto nella risposta alla parte successiva ...

È basato su XML, quindi è difficile da leggere come lo era ANT.

Prima di tutto, non vedo come puoi lamentarti del fatto che qualche aspetto di qualcosa "non è meglio di formica" come giustificazione per una cattiva reputazione. In secondo luogo, sebbene sia ancora XML, il formato dell'XML è molto più definito. Inoltre, poiché è così definito, è molto più facile creare un editor thick client sensato per un POM. Ho visto pagine lunghe e creare script che saltano dappertutto. Qualsiasi editor di script di build di formiche non lo renderà più appetibile, solo un altro lungo elenco di attività interconnesse presentate in un modo leggermente diverso.

Detto questo, ci sono alcune lamentele che ho visto qui che hanno o hanno avuto una certa validità, l'essere più grande

  • La documentazione è scarsa / mancante
  • Build riproducibili
  • L'integrazione di Eclipse è pessima
  • Bug

A cui la mia risposta è duplice. Innanzitutto, Maven è uno strumento molto più giovane di Ant o Make, quindi devi aspettarti che ci vorrà del tempo per raggiungere il livello di maturità di quelle applicazioni. Il secondo è, beh, se non ti piace, aggiustalo . È un progetto open source e usarlo e poi lamentarsi di qualcosa che chiunque può contribuire a risolvere mi sembra abbastanza assurdo. Non ti piace la documentazione? Contribuisci a renderlo più chiaro, più completo o più accessibile a un principiante.

Il problema delle build riproducibili si suddivide in due problemi, intervalli di versioni e aggiornamenti automatici dei plug-in Maven. Per gli aggiornamenti del plug-in, beh, a meno che non ti assicuri, quando ricostruisci un progetto un anno dopo, di utilizzare lo stesso identico JDK e la stessa identica versione di Ant, beh questo è lo stesso problema con un nome diverso. Per gli intervalli di versione, consiglio di lavorare su un plugin che produrrà un pom temporaneo con versioni bloccate per tutte le dipendenze dirette e transitive e lo renderà parte del ciclo di vita del rilascio di Maven. In questo modo i poms della build di rilascio sono sempre descrizioni esatte di tutte le dipendenze.


11

Si merita la reputazione che ha. Non tutti hanno bisogno della struttura rigida che gli sviluppatori di Maven pensavano fosse appropriata per ogni singolo progetto. È così inflessibile. E ciò che è "Pro" per molte persone, la gestione delle dipendenze, è IMHO il suo più grande "con". Non sono assolutamente a mio agio con Maven che scarica i jar dalla rete e perdo il sonno a causa delle incompatibilità (sì, la modalità offline esiste, ma allora perché dovrei avere tutte quelle centinaia di file xml e checksum). Decido quali librerie utilizzare e molti progetti hanno serie preoccupazioni sulle build che dipendono dalla connessione di rete.

Ancora peggio, quando le cose non funzionano, sei assolutamente perso. La documentazione fa schifo, la comunità è all'oscuro.


4
Sono d'accordo con questo. Penso che il valore della gestione delle dipendenze sia sopravvalutato. Certo è pulito quando tutto funziona, ma introduce diversi potenziali punti di guasto (per non parlare dei potenziali buchi di sicurezza). Puoi configurare il tuo server di repository per mitigare in qualche modo i problemi e bloccare i numeri di versione per evitare aggiornamenti imprevisti, ma preferisco comunque aggiungere semplicemente le dipendenze al controllo della versione poiché non cambiano spesso e garantisce una build ripetibile .
Dan Dyer

8

Un anno dopo volevo aggiornare questo: non ho più questa opinione sulla comunità Maven. Non scriverei questa risposta se la domanda fosse posta oggi. Aggiungerò la mia opinione attuale come risposta separata.


Questa è una risposta molto soggettiva, ma la domanda riguarda le opinioni, quindi ...

Mi piace Maven, e più lo conosco mi piace di più. Una cosa che ha influenzato i miei sentimenti al riguardo, tuttavia: la comunità di esperti è in gran parte incentrata su Sonatype ("la compagnia esperta", è dove lavorano molti dei Maven honchos), e Sonatype sta spingendo i suoi prodotti aziendali in modo piuttosto aggressivo sulla comunità.

Un esempio: il flusso di Twitter "Maven Book" si collega a una presunta introduzione alla gestione del repository .

Mi spiace, ma quella "introduzione" è per metà informativa e per metà di vendita per Nexus. Pop quiz: ci sono altri repo manager oltre a Nexus e Nexus Pro? Inoltre, cosa ha a che fare con il presunto libro Maven open source? Oh, giusto, il capitolo sulla gestione dei repository è stato suddiviso in un libro separato ... su Nexus. Eh. Se contribuisco al libro Maven, ricevo una commissione per referral se provo un aumento delle vendite di Nexus?

Immagina di partecipare a un forum di sviluppo Java ed è chiaro che i dipendenti Sun che discutono di Java avrebbero colto ogni possibile opportunità per parlare di NetBeans e "NetBeans Pro". Dopo un po 'perde parte del suo sentimento comunitario. Non ho mai avuto un'esperienza del genere con Ant.

Detto questo, penso che Maven sia un sistema molto interessante e utile (non lo chiamo uno strumento, come Ant, Maven è più ampio di quello) per la configurazione dello sviluppo software e la gestione delle build. La gestione delle dipendenze è una benedizione e una maledizione a volte, ma è rinfrescante e certamente non l'unico vantaggio offerto da Maven. Probabilmente sto reagendo un po 'troppo fortemente allo scellino Sonatype, ma secondo me fa male a Maven per associazione. Non so se questa opinione sia condivisa da qualcun altro.


2
Zac, sai che mi chiedevo se volessi saperne di più su Nexus Professional. :-)
Tim O'Brien

7

Penso che Maven abbia una cattiva reputazione perché impone una struttura al tuo progetto, mentre altri strumenti come Ant ti permettono di definire completamente la struttura come preferisci. D'accordo anche sul fatto che la documentazione è cattiva, ma penso che principalmente il brutto colpo che ottiene Maven sia perché le persone sono così abituate ad Ant.


2
Sono d'accordo sul fatto che inizialmente le persone possano perdere il controllo che avevano con Ant, ma una volta che un progetto arriverà ad accettare le convenzioni che Maven impone, ne vedranno davvero un aumento di produttività.
Taylor Leese

5
Non è vero, Maven ti permette di cambiare la struttura del progetto, ti suggerisce solo una struttura ampiamente utilizzata.
adrian.tarau

3
Non credo che questo sia vero. La maggior parte delle lamentele su Maven riguardano i modi in cui può fallire, quanto è lento o la documentazione. Non ho mai notato nessuno lamentarsi della struttura.
Dan Dyer

@ Dan Dyer: lo secondo. La struttura è in realtà una delle poche cose buone che fa Maven. È tutto il resto che rende Maven così orribile.
Carl Smotricz

6

Troppa magia.


3
Sii più specifico: cosa c'è di così magico che non è documentato?
whaley

4
È magico non appena devi cercare sul Web per 2 ore per scoprire perché qualcosa non funziona come previsto. Se vuoi un esempio specifico: perché il mio plugin non viene eseguito? Hai 2 ore.
Damien B

In realtà, ogni volta che faccio qualcosa che non comporti la ricerca sul web per 2 ore, comincio a sospettare di utilizzare lo strumento sbagliato per il lavoro o di aver gravemente frainteso / sottovalutato i requisiti.
Doug Moscrop,

6

Perché le persone insoddisfatte si lamentano mentre le persone soddisfatte non dicono di essere soddisfatte. Il punto è che ci sono utenti esperti molto più soddisfatti che insoddisfatti, ma questi ultimi fanno più rumore. Questo è un modello comune anche nella vita reale (ISP, operatore telefonico, trasporti, ecc.).


5

Il problema più importante per me è che Maven, se non configurato correttamente, potrebbe non produrre build ripetibili, a causa di:

  • archivi remoti inaffidabili;
  • dipendenze da plugin e librerie con versioni SNAPSHOT o nessuna versione.

Confrontalo con una build di formiche che, sebbene prolissa e fastidiosa IMO, funziona poiché tutti i vasi sono archiviati localmente.

La parte buona è che i problemi sono risolvibili:

  • usa il tuo repository esperto, che è diventato semplicissimo, sto usando Archiva con buoni risultati;
  • versione sempre correttamente le tue dipendenze. Maven ha iniziato a bloccare le versioni dei plugin nel super-POM a partire dalla 2.0.8 o 2.0.9 e tutte le tue dipendenze dovrebbero essere sulle versioni rilasciate.

+1 per il collegamento a un'implementazione di repository alternativa.
Donal Fellows

5

ottima idea - cattiva implementazione.

Recentemente ho spostato un progetto da Ant a Maven. Alla fine ha funzionato bene, ma ho dovuto usare due diverse versioni di maven-assembly-plugin e maven-jar-plugin nello stesso pom (ottenuto due profili) perché ciò che funzionava in una versione era rotto in un'altra.

Quindi è stato un bel mal di testa. La documentazione non è sempre eccezionale, ma devo ammettere che è stato relativamente facile trovare le risposte su Google.

assicurati di specificare sempre le versioni dei plug-in che utilizzi. Non aspettarti che la nuova versione sarà compatibile con le versioni precedenti.

Penso che la controversia derivi dal fatto che Maven si evolve ancora e il processo a volte è doloroso.

Saluti

v.


Sono d'accordo che l'idea è migliore dell'esecuzione. Non è un compito da poco scelto in loro difesa, ma mi chiedo regolarmente se le cose non avrebbero potuto essere fatte in modo più diretto.
Eelco

5

Mi piace Maven. L'ho usato dalla versione precedente alla 1.0. È uno strumento potente che, a conti fatti, mi ha fatto risparmiare una notevole quantità di tempo e ha migliorato la mia infrastruttura di sviluppo. Ma posso capire la frustrazione di alcune persone. Vedo 3 tipi di frustrazione:

  1. dove le cause sono preoccupazioni reali (ad esempio POM verbose, mancanza di documentazione),
  2. alcune sono informazioni sbagliate (ad es. "devi avere una connessione Internet per creare" - non è vero - non farlo, questo può essere evitato),
  3. un po 'è sfogato a Maven ma in realtà qualcun altro è colpevole ("non sparare al messaggero").

Per il primo caso, problemi reali - beh, certo, ci sono problemi, i POM sono prolissi, la documentazione potrebbe essere migliore. Eppure, nonostante ciò, è possibile ottenere buoni risultati con Maven in tempi rapidi. Rabbrividisco ogni volta che ottengo un progetto creato con ant e provo a importarlo nel mio IDE. Potrebbe essere necessario molto tempo per impostare la struttura della directory. con Maven, è solo un caso di aprire il file POM nell'IDE.

Per il secondo caso, Maven è complesso e le incomprensioni sono all'ordine del giorno. Se Maven 3 riesce a trovare un modo per affrontare questa complessità (o anche la complessità percepita) sarebbe un bene. maven richiede un investimento considerevole, ma, secondo la mia esperienza, l'investimento si ripaga rapidamente.

Per l'ultimo punto, penso che la lamentela sulle dipendenze transitive di Maven sia probabilmente l'esempio più noto.

Le dipendenze transitive sono la natura del software reale che impiega il riutilizzo. Le DLL di Windows, i pacchetti Debian, i pacchetti java, i pacchetti OSGi, persino il file di intestazione C ++ includono tutti dipendenze e soffrono del problema delle dipendenze. Se hai due dipendenze e ciascuna usa una versione diversa della stessa cosa, devi provare a risolverla in qualche modo. Maven non cerca di risolvere il problema della dipendenza, ma piuttosto lo porta in primo piano e fornisce strumenti per aiutare a gestire il problema, ad esempio segnalando conflitti e fornendo dipendenze coerenti per una gerarchia di progetti, e in effetti fornisce il controllo assoluto su le dipendenze di un progetto.

L'approccio di includere manualmente le dipendenze con ogni progetto (un poster dice che controlla tutte le dipendenze nel controllo del codice sorgente) corre il rischio di utilizzare la dipendenza sbagliata, come gli aggiornamenti trascurati quando una libreria viene aggiornata senza controllare gli aggiornamenti per le sue dipendenze. Per un progetto di qualsiasi dimensione, la gestione manuale delle dipendenze porterà sicuramente a errori. Con Maven, puoi aggiornare la versione della libreria che usi e le dipendenze corrette sono incluse. Per la gestione delle modifiche, puoi confrontare il vecchio set di dipendenze (per il tuo progetto nel suo insieme) con il nuovo set e qualsiasi modifica può essere attentamente esaminata, testata ecc.

Maven non è la causa del problema di dipendenza, ma lo rende più visibile. Nell'affrontare i problemi di dipendenza, maven rende esplicite le "modifiche" alle dipendenze (una modifica al tuo POM che sovrascrive la dipendenza), piuttosto che implicita, come nel caso dei jar gestiti manualmente nel controllo della versione, dove i jar sono semplicemente presenti, senza niente da supporto meteo sono la dipendenza corretta o meno.


5

Credo che Maven abbia una cattiva reputazione perché la maggior parte dei detrattori non ha osservato la combinazione di Maven + Hudson + Sonar . Se lo avessero fatto, avrebbero chiesto "come faccio a iniziare"?


+1 per aver menzionato Sonar.
Donal Fellows

1
L'ho visto. Non c'è ancora alcun motivo per usare Maven. Hudson e Sonar non hanno bisogno di Maven.
rk2010

5

Alcuni dei miei animali domestici irritano con Maven:

  • La definizione XML è super goffa e prolissa. Non hanno mai sentito parlare di attributi?

  • Nella sua configurazione predefinita, setaccia sempre la 'rete ad ogni operazione. Indipendentemente dal fatto che questo sia utile per qualcosa, sembra estremamente sciocco aver bisogno di un accesso a Internet per "pulire".

  • Di nuovo in impostazione predefinita, se non sto attento a specificare i numeri di versione esatti, estrarrà gli ultimi aggiornamenti dalla rete, indipendentemente dal fatto che queste versioni più recenti introducano errori di dipendenza. In altre parole, sei messo alla mercé della gestione della dipendenza di altre persone.

  • La soluzione a tutto questo accesso alla rete è disattivarlo aggiungendo l' -oopzione. Ma devi ricordarti di spegnerlo se vuoi davvero fare l'aggiornamento delle dipendenze!

  • Un'altra soluzione è installare il proprio server di "controllo del codice sorgente" per le dipendenze. Sorpresa: la maggior parte dei progetti ha già il controllo del codice sorgente, solo che funziona senza configurazioni aggiuntive!

  • Le build di Maven sono incredibilmente lente. Giocherellare con gli aggiornamenti di rete allevia questo, ma le build di Maven sono ancora lente. E orribilmente prolisso.

  • Il plugin Maven (M2Eclipse) si integra molto male con Eclipse. Eclipse si integra in modo abbastanza fluido con il software di controllo della versione e con Ant. L'integrazione di Maven è molto goffa e brutta al confronto. Ho accennato lento?

  • Maven continua ad essere pieno di bug. I messaggi di errore non sono utili. Troppi sviluppatori ne soffrono.


2
Non ho mai avuto Maven tirare l'ultima uscita da una dipendenza a meno che non stessi utilizzando una dipendenza SNAPSHOT o aggiunto una nuova funzionalità che richiedeva qualcosa. Se chiedo la versione 1.2.3 e ho la 1.2.3 nel mio repository locale, non ottengo nuovamente la 1.2.3.
Mike Cornell

1
Tu controlli le tue dipendenze dirette, sì. Chi controlla le dipendenze delle tue dipendenze?
Carl Smotricz

Per il tuo primo punto, sugli attributi, che dovrebbe essere affrontato nel prossimo, (per un lungo periodo ora lo ammetto) Maven 3.
mezmo

@mezmo: Sarebbe molto gradito. Grazie per le informazioni!
Carl Smotricz

4

Buona domanda. Ho appena iniziato un grande progetto al lavoro e parte dei progetti precedenti consisteva nell'introdurre la modularità alla nostra base di codice.

Ho sentito parlare male di Maven. In effetti, è tutto quello che ho mai sentito al riguardo. Ho cercato di introdurlo per risolvere l'incubo di dipendenza che stiamo vivendo attualmente. Il problema che ho riscontrato con Maven è che è abbastanza rigido nella sua struttura, cioè devi conformarti al layout del suo progetto perché funzioni per te.

So cosa dirà la maggior parte delle persone: non devi conformarti alla struttura. In effetti è vero, ma non lo saprai finché non avrai superato la curva di apprendimento iniziale, a quel punto hai investito troppo tempo per buttare via tutto.

La formica è usata molto in questi giorni e la adoro. Tenendo conto di ciò, mi sono imbattuto in un gestore delle dipendenze poco conosciuto chiamato Apache Ivy . Ivy si integra molto bene in Ant ed è facile e veloce ottenere la configurazione e il funzionamento di base del recupero dei JAR. Un altro vantaggio di Ivy è che è molto potente ma abbastanza trasparente; puoi trasferire build usando meccanismi come scp o ssh abbastanza facilmente; recupero delle dipendenze "a catena" su filesystem o repository remoti (la compatibilità con i repository Maven è una delle sue caratteristiche popolari).

Detto questo, ho trovato molto frustrante da usare alla fine: la documentazione è in abbondanza, ma è scritta in un cattivo inglese che può aumentare la frustrazione durante il debug o il tentativo di capire cosa è andato storto.

Rivisiterò Apache Ivy ad un certo punto durante questo progetto e spero che funzioni correttamente. Una cosa che ha fatto è stato consentire a noi come team di capire da quali librerie dipendiamo e ottenere un elenco documentato.

In definitiva penso che tutto si riduce a come si lavora come un individuo / squadra e che cosa avete bisogno per risolvere i vostri problemi di dipendenza.

Potresti trovare utili le seguenti risorse relative a Ivy:


1
Ivy non compete con Maven (forse con Maven Ant Tasks, ma non con Maven).
Pascal Thivent

1
Ivy non compete con Maven Ant Tasks, compete con la gestione delle dipendenze di Maven.
Damien B

@atc Questo era giusto !! : "So cosa dirà la maggior parte delle persone: non devi conformarti alla struttura. In effetti è vero, ma non lo saprai finché non avrai superato la curva di apprendimento iniziale, momento in cui hai investito troppo tempo andare a buttare via tutto ".
rk2010

4

Adoro Maven: aumenta la produttività e sono molto felice di non utilizzare più Ant (phew!)

Ma se potessi cambiare le cose sarebbe:

  1. Rendere pom.xml file meno dettagliato
  2. Rendi più semplice includere .jars non dal repository.

1
Penso che gli utenti di Maven sarebbero serviti meglio se gli IDE consentissero l'importazione di jar mancanti o di terze parti nei repository locali. Quanto sarebbe difficile avere una finestra di dialogo "seleziona l'importazione dei clic del barattolo"?
sal

@sal La mia ipotesi è che Maven non voglia promuovere una pratica che interrompe la portabilità.
Pascal Thivent

1
Considero il fatto che sia difficile aggiungere vasi da posti casuali un punto di forza. Se ti trovi in ​​un ambiente di squadra e devi usare un barattolo dispari, dovresti distribuire quel barattolo nel repository Maven del tuo team. In questo modo, il resto del team e i tuoi server CI eseguiranno la stessa build. Tutti gestiscono la stessa build è un fondamento della filosofia Maven.
Tunaranch

+1 per la cosa del barattolo. Portare i tuoi vasi precostruiti in una build (per qualsiasi motivo) è un dolore inutile.
Thorbjørn Ravn Andersen

@tunaranch personalmente mi piace che o le cose siano in Maven Central o (barattoli e tutto) in ciò che viene estratto dal controllo della versione. Fondamentalmente voglio essere in grado di portare il mio repository git su una chiavetta USB, controllarlo, eseguire "mvn clean install" e andare a pranzo ed essere attivo e funzionante.
Thorbjørn Ravn Andersen

4

Ci sono molte ragioni per cui alle persone non piace Maven, ma ammettiamolo sono molto soggettive . Maven oggi con alcuni buoni (e gratuiti) libri, una migliore documentazione, un set più ampio di plugin e molte build di progetti di successo referenziali non è lo stesso Maven di uno o due anni fa.

Usare Maven in progetti semplici è molto facile, con progetti più grandi / complicati è necessaria una maggiore conoscenza e una comprensione più profonda della filosofia Maven - forse a livello aziendale una posizione per guru Maven come amministratore di rete. La principale fonte di Maven odia le dichiarazioni sono spesso l' ignoranza .

Un altro problema per Maven è la mancanza di flessibilità come ad esempio in Ant. Ma ricorda Maven ha una serie di convenzioni: attenersi a esse sembra essere difficile all'inizio, ma alla fine spesso si risparmia dai problemi.

L'attuale successo di Maven dimostra il suo valore. Ovviamente nessuno è perfetto e Maven ha alcuni contro e le sue stranezze, ma secondo me Maven fa oscillare lentamente i suoi avversari.


@Pascal. In caso di problemi con Maven c'è uno stackoverflow e tu qui :)
cetnar

3

Non direi che ha una cattiva reputazione tanto quanto ha una ripetizione mista. Se il tuo progetto segue il paradigma della "convenzione sulla configurazione" sostenuto da Maven, puoi trarne grande vantaggio. Se il tuo progetto non si adatta bene alla visione del mondo di Maven, può diventare un peso.

A tal fine, se hai il controllo sul progetto, Maven potrebbe essere la strada da percorrere. Ma se non lo fai e il layout è determinato da qualcuno che non è un fan di Maven, potrebbe essere più un problema di quanto valga la pena. I progetti Maven più felici sono probabilmente quelli iniziati come progetti Maven.


"Non direi che ha una cattiva rappresentazione tanto quanto ha una ripetizione mista" - Direi che probabilmente è più preciso, solo le opinioni negative tendono a risaltare di più.
Dan

Sono d'accordo sul fatto che il porting di un progetto su Maven aumenta sperimentalmente la difficoltà rispetto alle dimensioni del progetto (progetto più grande da importare = importazione più difficile). utilizzare Maven per avviare un progetto è l'approccio migliore per utilizzare Maven. Altrimenti potrebbe non valerne la pena.
Luigimax

3

Per me, ci sono tanti vantaggi quanti sono i contro nell'usare Maven vs Ant per progetti interni. Per i progetti open source, tuttavia, penso che Maven abbia avuto un grande impatto nel rendere molti progetti molto più facili da costruire. Non è passato molto tempo da quando ci sono volute ore per compilare il progetto OSS Java (basato su formiche) medio, dover impostare un sacco di variabili, scaricare progetti dipendenti, ecc.

Puoi fare qualsiasi cosa con Maven che puoi fare con Ant, ma dove Ant non incoraggia alcuno standard, Maven ti suggerisce vivamente di seguire la sua struttura, o sarà più lavoro. È vero, alcune cose sono una seccatura da impostare con Maven che sarebbe facile da fare con Ant, ma il risultato finale è quasi sempre qualcosa che è più facile da costruire dal punto di vista delle persone che vogliono solo dare un'occhiata a un progetto e andare.


3

Se hai intenzione di scommettere la tua attività o il tuo lavoro su un progetto di sviluppo, vuoi avere il controllo delle basi, cioè il sistema di compilazione. Con Maven, non hai il controllo. È dichiarativo e opaco. Gli sviluppatori di maven-framework non hanno idea di come costruire un sistema trasparente o intuitivo e questo è chiaro dall'output del log e dalla documentazione.

La gestione delle dipendenze è molto allettante poiché potrebbe essere la tua stessa persona all'inizio del progetto, ma tieni presente che è fondamentalmente rotta e alla fine ti causerà molti mal di testa. Quando due dipendenze hanno dipendenze transitorie incompatibili, verrai bloccato da un nido di complessità che interromperà la build per l'intero team e bloccherà lo sviluppo per giorni. Il processo di compilazione con Maven è anche notoriamente incoerente per diversi sviluppatori nel tuo team a causa di stati incoerenti dei loro repository locali. A seconda di quando uno sviluppatore ha creato il proprio ambiente o su quali altri progetti sta lavorando, avranno risultati diversi. Scoprirai che stai eliminando l'intero repository locale e che Maven scarica nuovamente i jar molto più spesso rispetto alla prima configurazione per un ramo di sviluppo. Credo che OSGI sia un'iniziativa che sta tentando di risolvere questo problema fondamentale. Direi che forse, se qualcosa deve essere così complesso, la premessa fondamentale è sbagliata.

Sono un utente esperto / vittima da oltre 5 anni e devo dire che ti farà risparmiare molto più tempo per controllare le tue dipendenze nel tuo repository sorgente e scrivere compiti semplici e piacevoli. Con ant, sai ESATTAMENTE cosa sta facendo il tuo sistema di compilazione.

Ho sperimentato molte, molte settimane lavorative perse in diverse società a causa di problemi con Maven.

Recentemente ho provato a riportare in vita un vecchio progetto GWT / Maven / Eclipse e dopo 2 settimane di tutto il mio tempo libero, non riesco ancora a costruirlo in modo coerente. È ora di ridurre le mie perdite e svilupparmi usando formica / eclissi, penso ...


3

La risposta breve: ho trovato molto difficile mantenere un sistema di compilazione Maven e vorrei passare a Gradle il prima possibile.

Lavoro con Maven da oltre quattro anni. Mi definirei un esperto di sistemi di build perché nelle ultime (almeno) cinque aziende in cui ho lavorato, ho fatto importanti ristrutturazioni sull'infrastruttura di build / deploy.

Alcune delle lezioni che ho imparato:

  • La maggior parte degli sviluppatori tende a non passare molto tempo a pensare ai sistemi di compilazione; di conseguenza, la build si trasforma in un pasticcio di hack, ma lo apprezzano quando quel pasticcio viene ripulito e razionalizzato.
  • Nell'affrontare la complessità, preferirei avere un sistema trasparente che esponga la complessità (come Ant) piuttosto che uno che cerchi di rendere semplici le cose complesse imponendo rigide restrizioni, come Maven. Pensa a Linux rispetto a Windows.
  • Maven ha molti buchi nella funzionalità che richiedono soluzioni alternative bizantine. Questo porta a file POM che sono incomprensibili e non mantenibili.
  • Ant è super flessibile e comprensibile, ma anche i file Ant possono diventare piuttosto grandi, perché è di basso livello.
  • Per qualsiasi progetto significativo, gli sviluppatori devono creare la propria struttura di build / implementazione oltre a ciò che lo strumento fornisce; l'idoneità della struttura al progetto ha molto a che fare con la facilità di manutenzione. I migliori strumenti ti supporteranno nella creazione di una struttura e non ti combatteranno.

Ho esaminato un po 'Gradle e sembra che abbia il potenziale per essere il migliore di entrambi i mondi, consentendo un mix di descrizione della build dichiarativa e procedurale.


3

È più complicato del linguaggio che hai usato per scrivere il tuo progetto. Configurarlo correttamente è più difficile della programmazione effettiva.


3

Ho lottato per superare la maggior parte / tutti gli aspetti negativi menzionati qui e obiezioni simili da parte dei compagni di squadra e sono d'accordo con tutti loro. Ma ho resistito e continuerò a farlo mantenendo fermo l'unico obiettivo che solo Maven (o forse gradle) offre davvero.

Se stai ottimizzando per i peer ( sviluppatori open source ), ant / make / qualunque cosa farà. Se fornisci funzionalità a non peer ( utenti ), solo maven / gradle / etc lo farà.

Solo Maven ti consente di rilasciare un piccolo pacchetto di codice sorgente + poms (nessun vaso di dipendenza lib / binario incorporato con nomi criptici e nessuna informazione di dipendenza) con un layout di progetto standard ben documentato che può essere caricato da qualsiasi IDE da qualcuno che non ha assorbito le convenzioni di layout idiosincratiche degli sviluppatori. E c'è una procedura di installazione con un solo pulsante (installazione mvn) che costruisce tutto mentre acquisisce eventuali dipendenze mancanti.

Il risultato è una facile rampa che gli utenti possono seguire per trovare la loro strada nel codice, dove i poms possono indirizzarli alla documentazione pertinente.

A parte questo requisito (indispensabile), non mi piace Maven tanto quanto chiunque.

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.