comparaison de sbt et Gradle [fermé]

110

Je plonge dans Scala et remarque sbt. J'ai été assez satisfait de Gradle dans les projets java / groovy, et je sais qu'il existe un plugin scala pour Gradle.

Quelles pourraient être de bonnes raisons de privilégier sbt à Gradle dans un projet Scala?

scala sbt gradle

— Hans Westerbeek
source

SBT, dans un certain sens, est comme un Vim: si vous le grokez, vous serez ravi. Et au fait, il y a aussi maven et lein (a été créé pour clojure, mais fonctionne aussi avec scala).

— om-nom-nom

18

Ne vous sentez pas obligé de passer à SBT. Certains membres bien connus de la communauté Scala utilisent Gradle. Au lieu de cela, utilisez SBT comme une expérience, sachant que vous pouvez simplement utiliser Gradle à la place.

— Daniel C.Sobral

6

merci à tous ... Après avoir lu vos idées, je vais rester avec Gradle. Il me semble que c'est là que se dérouleront la plupart des efforts de création d'outils pour l'espace JVM alors que nous laissons Maven derrière nous.

— Hans Westerbeek

10

Il est ennuyeux que cette question soit marquée comme «basée sur l'opinion» ici, probablement par des personnes qui ne travaillent pas dans l'espace JVM tout le temps (et qui manquent donc de surveillance). Les réponses ci-dessous sont factuelles et dépourvues de guerre sainte.

— Hans Westerbeek du

4

Non, ces réponses sont principalement des déclarations de faits vérifiables, pas des opinions. Bien que cette question puisse susciter des réponses inutiles, elle ne l’a pas fait. Il doit rester ouvert en tant que description utile des différences réelles entre les outils.

— erickson

61

Notez qu'une différence clé entre SBT et Gradle est sa gestion des dépendances :

SBT : Ivy , avec une révision qui peut être donnée comme une version fixe (1.5.2, par exemple) ou comme la dernière (ou dynamique).
Voir « Dépendance Ivy »
Cela signifie que le support du mécanisme «-SNAPSHOT» peut être problématique, même si Mark Harrah détaille dans ce fil :

Il est vrai que le cache peut devenir confus, mais ce n'est pas vrai qu'Ivy ne comprend pas la résolution des instantanés. Eugene a expliqué ce point dans un autre fil, peut-être sur la liste des administrateurs. Il y a un problème avec la mise à jour automatique de sbt qui a été résolu dans la version 0.12.

Ce que Ivy ne prend pas en charge, pour autant que je sache, c'est la publication d'instantanés à la manière de Maven. Je crois que j'ai dit cela ailleurs, mais si quelqu'un veut améliorer la situation, mon opinion est qu'il vaut mieux faire l'effort de travailler avec l'équipe Gradle pour réutiliser son code de gestion des dépendances.

Gradle : Ce fil mentionne ( Peter Niederwieser ):

Juste pour vous le faire savoir, les problèmes avec les dépendances de snapshot Ivy et Maven étaient l'une des raisons pour lesquelles Gradle a finalement remplacé Ivy par son propre code de gestion des dépendances. C'était une tâche énorme, mais nous a apporté beaucoup de bonté.

Ce tweet mentionne que toute la situation pourrait évoluer à l'avenir:

Mark a dit dans le passé qu'il était intéressé à utiliser Gradle au lieu d'Ivy pour SBT.

(les deux outils peuvent apprendre l'un de l'autre )

— VonC
source

1

Le plus gros inconvénient que j'ai jamais rencontré est sbt, c'est que vous ne pouvez pas spécifier pour la règle de ne pas recompiler chaque fois qu'elle est mentionnée. Les règles intégrées pour java et scala ont cette fonctionnalité mais elle n'est pas exposée pour l'écriture de règles personnalisées. Ainsi, chaque fois que vous générez un fichier programme ou une documentation et même si vous générez un fichier jar, votre tâche serait exécutée à chaque appel, quelles que soient les modifications apportées aux sources. Même faire est assez intelligent, mais pas sbt

— ayvango

1

@ayvango Ce n'est pas le cas de nos jours sbt. Il existe de nombreux plugins qui utilisent cette fonctionnalité, comme android-sdk-plugin

— dant3

Savez-vous quelle API est utilisée pour cette fonctionnalité?

— ayvango

c'est donc quelque chose qui manque quand on compare à la fois maven et gradle? C'est étrange

— tribbloid

53

Pour moi, les principales caractéristiques de SBT sont:

Compilation rapide (plus rapide que fsc).
Compilation / tests continus: la commande ~testrecompilera et testera votre projet à chaque fois que vous enregistrez une modification.
Compilation croisée et publication croisée, sur plusieurs versions de scala.
Récupération automatique des dépendances avec la compatibilité de version scala correcte.

Les inconvénients sont:

Une syntaxe hiéroglyphique qui a tendance à décourager les nouveaux utilisateurs (surtout s'ils viennent de Java)
Pas de moyen simple de définir une "tâche": si vous avez besoin d'une procédure de construction spéciale, vous devrez soit trouver un plugin, soit écrire un plugin vous-même.

— paradigmatique
source

Ai-je raison de dire que la fonctionnalité de compilation / publication croisée est / était nécessaire en raison des problèmes que Scala a rencontrés avec l'incompatibilité binaire vers l'arrière?

— Hans Westerbeek

1

Oui. Et ces problèmes peuvent se reproduire lors du passage à Scala 2.10.

— paradigmatic le

1

Il y a deux autres différences que j'ajouterais: * Dans SBT, il est plus facile d'autogérer les dépendances, IMO. * Le testeur SBT semble plus rapide; Je soupçonne qu'il y a une concurrence rusée impliquée ici, mais je suppose. SBT semble être un produit plus performant mais moins mature.

— Rick-777

25

+1 pour l'inconvénient de la «syntaxe hiéroglyphique». C'est mon plus gros reproche avec SBT. La surcharge des opérateurs conduit toujours à des abus: - /

— Ron Dahlgren

7

La syntaxe cryptique SBT fait ressortir le pire de scala. Gradle est basé sur un modèle de domaine bien pensé et une syntaxe simple.

— nemoo

40

sbt est un DSL Scala et pour cela Scala est un citoyen de première classe, donc en principe, il semble être un bon choix.

Mais sbt souffre de changements incompatibles majeurs entre les versions, ce qui rend difficile de trouver le bon plugin fonctionnel pour une tâche et de le faire fonctionner.

J'ai personnellement abandonné sbt, car cela posait plus de problèmes qu'il n'en résolvait. Je suis en fait passé à gradle.

Allez comprendre.

— Jens Schauder
source

2

Autant que je sache, il n'y a eu qu'un seul changement très important: lorsque sbt est passé de 0.7.x à 0.1.x

— om-nom-nom

1

Si vous utilisez un plugin pour sbt 0.11.2, puis passez à sbt 0.12, vous devez attendre que l'auteur du plugin compile une nouvelle version ou le fasse vous-même. idea-sbt en est un exemple.

— fmpwizard

4

@fmpwizard La ligne sbt 0.12 n'est pas encore sortie ... Arrêtez de diffuser du FUD.

— paradigmatic

3

Ce n'est pas le sbt qui est impossible à utiliser, notre équipe l'utilise. Mais mon commentaire était de soutenir cette réponse, qui disait "... Mais sbt souffre de changements incompatibles majeurs entre les versions, ce qui rend difficile de trouver le bon plugin fonctionnel pour une tâche et de le faire fonctionner ..." Comme vous le remarquez , Je ne peux pas simplement utiliser le plugin scct, j'ai dû le modifier (oui petit changement, mais ensuite j'ai dû le publier quelque part pour que toute mon équipe puisse y accéder) Une douleur sans raison.

— fmpwizard

3

Êtes-vous capable de faire une compilation croisée pour différentes versions de Scala en utilisant gradle?

— Machisuji

4

Je suis assez nouveau dans gradle, et très nouveau dans sbt - ce que j'aime vraiment dans sbt jusqu'à présent, c'est la console interactive. Cela me permet d'utiliser des commandes comme «inspecter» pour avoir une meilleure idée de ce qui se passe. AFAIK gradle ne fournit pas quelque chose comme ce atm.

— Eugenevd
source

-11

Sbt et gradle, tous deux sont basés sur des langages typés statiquement ... mais sbt a peu d'avantages:

meilleur support des plugins, spécialement les autoplugins
création de tâches et gestion des dépendances entre les tâches
sbt convient particulièrement aux projets scala dans le sens où il prend en charge les builds incrémentiels et la plupart des sbt lui-même sont écrits en scala et les définitions de build sbt sont écrites en scala
sbt prend en charge le shell interactif avec de nombreuses tâches intégrées utiles
Le cycle de vie par défaut de sbt est assez utile et permet aux novices de démarrer avec moins d'effort

— Saby
source

1

Gradle est basé sur groovy qui n'est pas un langage typé statiquement.

— Vistritium

Gradle gère les dépendances entre les tâches, il est aussi simple que possible de créer une tâche, je ne sais pas comment il peut être plus facile d'écrire un plugin que pour gradle qui peut prendre des plugins groovy, Java, gradle et peut-être plus.

— Johnride