Pro e contro dell'utilizzo di sbt vs maven nel progetto Scala [chiuso]

138

Quale strumento di costruzione è il migliore per Scala? Quali sono i pro e i contro di ciascuno di essi? Come determinare quale di questi utilizzare in un progetto?

scala maven sbt

— Konstantin Solomatov
fonte

Sono passato da Maven a Gradle per i progetti Scala, grazie al suo supporto superiore per build multi-modulo. L' esperienza su Twitter con SBT è descritta da loro come "dolore accecante" e stanno cercando di allontanarsi da esso (con Maven come punto di interruzione in quel processo).

— Ben Manes,

Un'altra bella domanda chiusa ...

— Cedric H.

Così tante buone domande che vedo che sono appena chiuse; Non so chi dia il potere a queste persone di decidere arbitrariamente di chiudere una domanda o no. Non prendo nemmeno attenzione al fatto che siano vicini o meno.

— user1888243

Essere d'accordo. Fortunatamente abbiamo 2 risposte prima che questa domanda venga chiusa. Scarso per chi vota per chiudere questa domanda ...

— hqt

Risposte:

Stiamo usando Maven per costruire progetti Scala al lavoro perché si integra bene con il nostro server CI. Potremmo semplicemente eseguire uno script di shell per dare il via a una build, ovviamente, ma abbiamo un sacco di altre informazioni che escono da Maven e che vogliamo entrare in CI. Questo è l'unico motivo per cui riesco a pensare di usare Maven per un progetto Scala.

Altrimenti, basta usare SBT. Ottieni l'accesso alle stesse dipendenze (davvero la parte migliore di Maven, IMHO). Ottieni anche la compilazione incrementale, che è enorme. La capacità di avviare una shell all'interno del tuo progetto, che è anche grandiosa.

ScalaMock funziona solo con SBT e probabilmente vorrai usarlo piuttosto che una libreria di derisione Java. Inoltre, è molto più semplice estendere SBT poiché puoi scrivere il codice scala completo nel file build, quindi non devi passare attraverso tutto il rigamarole della scrittura di un Mojo.

In breve, usa SBT a meno che tu non abbia davvero bisogno di una stretta integrazione nel tuo server CI.

— mblinn
fonte

Non sono in disaccordo con nessuno dei precedenti, ma volevo solo sottolineare che sto scrivendo ScalaMock 3 , uno dei cui obiettivi principali è quello di rendere più semplice il supporto di altri sistemi di compilazione.

— Paul Butcher,

Solo per completezza, vale la pena ricordare che ScalaMock 2 funziona perfettamente con qualsiasi sistema di compilazione (è solo un barattolo) fintanto che non è necessario utilizzare mock generati (cioè purché sia necessario solo deridere tratti / interfacce ).

— Paul Butcher,

scala-maven-plugin fornisce la compilazione incrementale salvata come SBT

— Nikita Volkov,

perché non hanno semplicemente scritto una compilation incrementale per Maven? IMHO, sbt è un esempio archeologico di una sindrome NIH non trattata ...

— Cpt. Senkfuss,

Perché problemi con CI dovuti a SBT?

— Daniel,

La domanda rischia di generare molte opinioni; sarebbe meglio avere un chiaro elenco di requisiti o una descrizione del proprio ambiente, conoscenze precedenti, ecc.

FWIW, ci sono più opinioni in questo thread della mailing list scala .

I miei 2c sono: vai con sbt se non hai requisiti specifici

per progetti semplici, è totalmente senza sforzo (non è nemmeno necessario un file di build fino a quando non si hanno dipendenze)
è comunemente usato nei progetti open source Scala. Puoi facilmente conoscere la configurazione dando un'occhiata ai progetti di altre persone. Inoltre, molti progetti presuppongono che tu usi sbt e ti fornisca istruzioni copia + incolla pronte per aggiungerle come dipendenza al tuo progetto.
se si utilizza IntelliJ IDEA, può essere totalmente integrato. IDEA può essere utilizzato da sbt per compilare continuamente il progetto e viceversa è possibile utilizzare sbt per generare rapidamente progetti IDEA . L'ultimo è estremamente utile se ci si trova in un ciclo di "snapshot" con a seconda di altre librerie che vengono trasferite dalla versione secondaria alla versione secondaria: basta chiudere il progetto, aggiornare la versione nel file di build, rieseguire ilgen-idea attività e riaprire il progetto: aggiornamenti eseguiti.
viene pronto con la maggior parte dei compiti di cui avrete bisogno ( compile, test, run, doc, publish-local, console) - la consoleè una delle migliori caratteristiche.
alcune persone evidenziano la caratteristica secondo cui le dipendenze possono essere repository di origine acquisiti direttamente da GitHub. Non l'ho usato, quindi non posso commentare qui.

Alcune persone odiano sbt perché usa Ivy per la gestione delle dipendenze (non posso commentare i suoi pro e contro, ma il più delle volte è un problema), alcune persone odiano sbt perché specifichi il file build in termini di un Scala DSL anziché XML. Alcune persone sono state deluse dal fatto che il formato di sbt sia cambiato da v0.7 a v0.10, ma ovviamente la migrazione non influirà su di te se inizi da zero.

— 0__
fonte

Odio sbt perché il suo abuso di operatori simbolici e alcune decisioni stupide, come entrambi supportano i formati di definizione .sbt e .scala ma li mettono in posizioni diverse, e le dichiarazioni in .sbt devono essere separate da una riga almeno vuota, ecc. I documenti di sbt stanno migliorando ma non abbastanza in questo momento. Quello che mi manca di più sono alcuni file di esempio .sbt / .scala completi (dal minimo al reale) spiegati riga per riga, che coprono tutte le funzionalità di sbt. Detto questo, uso sbt ogni giorno perché Maven fa schifo molto di più.

— xiefei,

Peccato che questa domanda sia stata chiusa, sono sicuro che ci sono anche differenze di fatto: ad esempio questo estratto dal libro Manning su SBT: "Se ci sono dipendenze tra gli obiettivi di Maven (diciamo che un obiettivo produce un file che viene consumato da un altro) quindi non puoi parallelizzare la tua build con Maven. Con sbt, devi specificare una dipendenza esplicita tra le attività. Ciò consente a sbt di eseguire attività in parallelo DI DEFAULT. Se l'attività A dipende da B e C dipende anche da B, allora sbt esegue l'attività B e quindi esegue A e C in parallelo. " Spero che questo commento aiuti alcuni lettori.

— jhegedus,

Ho trovato questa discussione molto utile. Molto spesso penso che i moderatori di Stackoverflow chiudano le discussioni troppo avidamente. Chi se ne frega se sono "fuori tema" quando sono molto spesso esattamente ciò che gli utenti stanno cercando (e trovano attraverso le ricerche sul web). È come se le mod di Stackoverflow stessero cercando di ricreare intenzionalmente xkcd 979 .

— Ville,

@Ville Anche i miei pensieri. Downvoting, editing e chiusura sono diventati troppo aggressivi.

— ankush981

Per chiunque lo guardi ora, i reclami di @ xiefei sono stati risolti. SBT ha eliminato molti più operatori / sintassi personalizzati e le istruzioni nei file / sbt non necessitano più di separazioni di spazi.

— Grogs,