confronto tra sbt e Gradle [chiuso]

110

Mi sto immergendo in Scala e ho notato sbt. Sono stato abbastanza soddisfatto di Gradle nei progetti java / groovy e so che esiste un plug-in scala per Gradle.

Quali potrebbero essere buone ragioni per preferire sbt a Gradle in un progetto Scala?

scala sbt gradle

— Hans Westerbeek
fonte

SBT in un certo senso è come un Vim: se lo gridi, sarai contento. E a proposito, ci sono anche maven e lein (è stato creato per clojure, ma funziona anche con scala).

— om-nom-nom

18

Non sentirti sotto pressione per passare a SBT. Alcuni noti membri della comunità Scala usano Gradle. Invece, usa SBT come esperimento, sapendo che puoi semplicemente usare Gradle invece.

— Daniel C. Sobral,

6

grazie a tutti ... Dopo aver letto le vostre intuizioni, rimarrò con Gradle. Mi sembra che sia lì che sarà la maggior parte degli sforzi per gli strumenti di costruzione per lo spazio JVM quando lasceremo Maven alle spalle.

— Hans Westerbeek

10

È fastidioso che questa domanda sia stata contrassegnata come "basata sull'opinione" qui, probabilmente da persone che non lavorano sempre nello spazio JVM (e quindi prive della supervisione). Le risposte seguenti sono reali e prive di guerre sacre.

— Hans Westerbeek

4

No, quelle risposte sono principalmente dichiarazioni di fatti verificabili, non opinioni. Sebbene questa domanda possa attirare risposte inutili, in realtà non lo ha fatto. Dovrebbe rimanere aperto come utile descrizione delle effettive differenze tra gli strumenti.

— erickson

61

Nota che una differenza fondamentale tra SBT e Gradle è la sua gestione delle dipendenze :

SBT : Ivy , con una revisione che può essere data come fissa (1.5.2, per esempio) o come ultima (o dinamica).
Vedi " Ivy Dependency "
Ciò significa che il supporto del meccanismo "-SNAPSHOT" può essere problematico, anche se Mark Harrah dettagli in questo thread :

È vero che la cache può confondersi, ma non è vero che Ivy non capisce la risoluzione degli snapshot. Eugene ha spiegato questo punto in un altro thread, forse nell'elenco degli amministratori. C'è un problema con l'aggiornamento automatico di sbt che è stato risolto in 0.12.

Quello che Ivy non supporta, per quanto ne so, è la pubblicazione di istantanee nel modo in cui lo fa Maven. Credo di averlo affermato altrove, ma se qualcuno vuole migliorare la situazione, la mia opinione è che è meglio spendere gli sforzi lavorando con il team di Gradle per riutilizzare il proprio codice di gestione delle dipendenze.

Gradle : Questo thread menziona ( Peter Niederwieser ):

Solo per farti sapere, i problemi con le dipendenze degli snapshot di Ivy e Maven sono stati uno dei motivi per cui Gradle alla fine ha sostituito Ivy con il proprio codice di gestione delle dipendenze. È stato un grande compito, ma ci ha portato tanta bontà.

Questo tweet menziona che l'intera situazione potrebbe evolversi in futuro:

Mark ha detto in passato che era interessato a usare Gradle invece di Ivy per SBT.

(entrambi gli strumenti possono imparare l'uno dall'altro )

— VonC
fonte

1

L'inconveniente più grave che abbia mai incontrato è sbt è che non è possibile specificare che la regola non si ricompili ogni volta che viene menzionata. Le regole incorporate per java e scala hanno questa funzionalità ma non sono esposte per scrivere regole personalizzate. Quindi ogni volta che si genera un file di programma o una documentazione e anche se si genera un file jar, l'attività verrà eseguita a ogni chiamata indipendentemente da eventuali modifiche ai sorgenti. Anche make è abbastanza intelligente, ma non sbt

— ayvango

1

@ayvango Non è il caso di sbt di oggi. Ci sono molti plugin che utilizzano questa funzionalità, come android-sdk-plugin

— dant3

Sai quale API viene utilizzata per quella funzionalità?

— ayvango

quindi questo è qualcosa che manca all'edera rispetto a Maven e Gradle? È strano

— tribbloide

53

Per me le caratteristiche principali di SBT sono:

Compilazione veloce (più veloce di fsc ).
Compilazione / verifica continua: il comando ~test ricompilerà e testerà il tuo progetto ogni volta che salvi una modifica.
Cross-compilation e cross-publishing, attraverso diverse versioni in scala.
Recupero automatico delle dipendenze con la corretta compatibilità della versione scala.

Gli svantaggi sono:

Una sintassi geroglifica che tende a scoraggiare i nuovi utenti (soprattutto se provengono da Java)
Non è un modo semplice per definire un "compito": se hai bisogno di una speciale procedura di compilazione, dovrai trovare un plugin o scriverlo tu stesso.

— paradigmatico
fonte

Ho ragione sul fatto che c'era / c'era bisogno della funzionalità di compilazione / pubblicazione incrociata a causa dei problemi che Scala ha avuto con l'incompatibilità binaria all'indietro?

— Hans Westerbeek,

1

Sì. E questi problemi possono ripresentarsi quando si passa a Scala 2.10.

— paradigmatico

1

Ci sono altre due differenze che aggiungerei: * In SBT, è più facile autogestire le dipendenze, IMO. * Il test runner SBT sembra più veloce; Sospetto che qui sia coinvolta un'astuta concorrenza, ma immagino. SBT sembra un prodotto più capace ma un po 'meno maturo.

— Rick-777

25

+1 per lo svantaggio della "sintassi geroglifica". Questa è la mia più grande lamentela con SBT. Il sovraccarico dell'operatore porta sempre ad abusi: - /

— Ron Dahlgren

7

La sintassi criptica SBT tira fuori il peggio in scala. Gradle si basa su un modello di dominio ben congegnato e una sintassi semplice.

— nemoo

40

sbt è un DSL di Scala e per questo Scala è un cittadino di prima classe, quindi in linea di principio sembra essere una buona misura.

Ma sbt soffre di importanti modifiche incompatibili tra le versioni, il che rende difficile trovare il plugin funzionante corretto per un'attività e farlo funzionare.

Personalmente ho rinunciato a sbt, poiché causava più problemi di quanti ne risolvesse. In realtà sono passato a gradle.

Vai a capire.

— Jens Schauder
fonte

2

Per quanto ne so, c'è stato solo un cambiamento molto importante: quando sbt è passato da 0.7.x a 0.1.x

— om-nom-nom

1

Se usi un plugin per sbt 0.11.2 e poi vai a sbt 0.12, devi aspettare che l'autore del plugin compili una nuova versione o fallo da solo. idea-sbt è un esempio.

— fmpwizard

4

@fmpwizard La linea sbt 0.12 non è stata ancora rilasciata ... Smetti di diffondere FUD.

— paradigmatico

3

Non è impossibile usare lo sbt, lo usa il nostro team. Ma il mio commento era di sostenere questa risposta, che diceva "... Ma sbt soffre di importanti modifiche incompatibili tra le versioni, il che rende difficile trovare il plugin funzionante corretto per un'attività e farlo funzionare ..." Come hai notato , Non posso semplicemente usare il plugin scct, ho dovuto modificarlo (sì piccola modifica, ma poi ho dovuto pubblicarlo da qualche parte in modo che tutto il mio team potesse accedervi) Un dolore senza una buona ragione.

— fmpwizard

3

Sei in grado di fare cross compilation per diverse versioni di Scala usando gradle?

— Machisuji

4

Sono abbastanza nuovo per gradle e molto nuovo per sbt - quello che mi piace davvero di sbt finora è la console interattiva. Mi consente di utilizzare comandi come "inspect" per avere un'idea migliore di cosa sta succedendo. AFAIK gradle non fornisce qualcosa di simile a questo bancomat.

— eugenevd
fonte

-11

Sbt e gradle, entrambi sono basati su linguaggi tipizzati staticamente ... ma sbt ha pochi vantaggi:

migliore supporto per i plugin, specialmente gli autoplugin
creazione di attività e gestione delle dipendenze tra le attività
sbt si adatta specialmente ai progetti scala nel senso che supporta build incrementali e la maggior parte dello stesso sbtè scritto in scala e le definizioni di build sbt sono scritte in scala
sbt ha il supporto interative della shell con molti utili compiti incorporati
Il ciclo di vita predefinito di sbt è piuttosto utile e può far iniziare i principianti con molto meno sforzo

— Saby
fonte

1

Gradle si basa su groovy che non è un linguaggio tipizzato staticamente.

— Vistritium

Gradle gestisce la dipendenza tra le attività, è il più semplice possibile creare un'attività, non ho idea di come possa essere più facile scrivere un plug-in rispetto a gradle che può accettare plug-in groovy, Java, gradle e possibilmente altro.

— Johnride