Avantages et inconvénients de l'utilisation de sbt par rapport à maven dans un projet Scala

Question

Quel outil de construction est le meilleur pour Scala ? Quels sont les avantages et les inconvénients de chacun d'eux ? Comment déterminer lequel d'entre eux utiliser dans un projet ?

Answer 1

Nous utilisons Maven pour construire des projets Scala au travail car il s'intègre bien à notre serveur CI. Nous pourrions simplement exécuter un script shell script pour lancer une construction, bien sûr, mais nous avons un tas d'autres informations qui sortent de Maven et que nous voulons transférer dans CI. C'est à peu près la seule raison que je vois d'utiliser Maven pour un projet Scala.

Sinon, utilisez simplement le SBT. Vous avez accès aux mêmes dépendances (ce qui est vraiment la meilleure partie de Maven, à mon avis). Vous obtenez également une compilation incrémentale, ce qui est énorme. La possibilité de démarrer un shell à l'intérieur de votre projet, ce qui est également génial.

ScalaMock ne fonctionne qu'avec SBT, et vous voudrez probablement l'utiliser plutôt qu'une bibliothèque de mocking Java. En plus de cela, c'est beaucoup Il est plus facile d'étendre SBT puisque vous pouvez écrire du code scala complet dans le fichier de construction, sans avoir à passer par toutes les étapes de l'écriture d'un Mojo.

En bref, utilisez simplement SBT à moins que vous n'ayez vraiment besoin d'une intégration étroite dans votre serveur de CI.

Answer 2

La question risque de susciter de nombreuses opinions ; il serait préférable de disposer d'une liste claire d'exigences ou d'une description de votre environnement, de vos connaissances antérieures, etc.

Pour info, il y a plus d'opinions dans ce fil de discussion de la liste de diffusion scala .

Mes 2c sont : Choisissez sbt si vous n'avez pas d'exigences spécifiques.

• pour les projets simples, c'est totalement sans effort (vous n'avez même pas besoin d'un fichier de compilation tant que vous n'avez pas de dépendances)
• il est couramment utilisé dans les projets open source Scala. Vous pouvez facilement apprendre la configuration en jetant un coup d'œil aux projets d'autres personnes. De plus, de nombreux projets partent du principe que vous utilisez sbt et vous fournissent les éléments suivants instruction de copier/coller prête à l'emploi pour les ajouter comme dépendance à votre projet.
• si vous utilisez IntelliJ IDEA, il peut être totalement intégré. Vous pouvez demander à IDEA d'utiliser sbt pour compiler continuellement votre projet, et vice versa vous pouvez utiliser sbt pour rapidement générer des projets IDEA . Cette dernière est extrêmement utile si vous êtes dans un cycle de "snapshot" et que vous dépendez d'autres de vos propres bibliothèques qui passent d'une version mineure à une autre - il suffit de fermer le projet, de mettre à jour la version dans le fichier de construction, de relancer la commande gen-idea et rouvrir le projet : mises à jour effectuées.
• est livré prêt avec la plupart des tâches dont vous aurez besoin ( compile , test , run , doc , publish-local , console ) -- le console est l'une des meilleures caractéristiques.
• Certaines personnes soulignent que les dépendances peuvent être des dépôts de sources directement récupérés sur GitHub. Je n'ai pas utilisé cette fonctionnalité et je ne peux donc pas faire de commentaires ici.

Certaines personnes détestent sbt parce qu'il utilise Ivy pour la gestion des dépendances (je ne peux pas me prononcer sur ses avantages et inconvénients, mais la plupart du temps, c'est un non problème), certaines personnes détestent sbt parce que vous spécifiez le fichier de construction en termes de DSL Scala au lieu de XML. Certaines personnes ont été déçues que le format de sbt ait changé de la v0.7 à la v0.10, mais évidemment la migration ne vous affectera pas si vous partez de zéro.