Avantages et inconvénients de l'utilisation de sbt vs maven dans le projet Scala [fermé]
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?
2 réponses
Nous utilisons Maven pour construire des projets Scala au travail car il s'intègre bien avec notre serveur CI. Nous pourrions simplement exécuter un script shell pour lancer une construction, bien sûr, mais nous avons un tas d'autres informations qui sortent de Maven que nous voulons aller dans CI. C'est la seule raison pour laquelle je peux penser à utiliser Maven pour un projet Scala.
Sinon, utilisez simplement SBT. Vous avez accès aux mêmes dépendances (vraiment la meilleure partie de maven, à mon humble avis). Vous obtenez également l'incrémental compilation, 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 Mocking Java. En plus de cela, il est beaucoup Plus Facile d'étendre SBT puisque vous pouvez écrire du code Scala complet dans le fichier de construction, de sorte que vous n'avez pas à passer par toute la rigamarole d'écrire un Mojo.
En bref, utilisez simplement SBT sauf si vous avez vraiment besoin d'une intégration étroite dans votre serveur CI.
La question risque de générer beaucoup d'opinions; il serait préférable d'avoir une liste claire des exigences ou une description de votre environnement, de vos connaissances antérieures, etc.
FWIW, il y a plus d'opinions dans ce fil de discussion de la liste de diffusion scala .
Mes 2c sont: Allez avec 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 construction jusqu'à ce que vous ayez des dépendances)
- c'est couramment utilisé dans les projets Open source Scala. Vous pouvez facilement en apprendre davantage sur la configuration en jetant un coup d'œil sur les projets d'autres personnes. De plus, de nombreux projets supposent que vous utilisez sbt et vous fournissez instruction copier+coller prête à l'emploi pour les ajouter en tant que dépendance à votre projet.
- Si vous utilisez IntelliJ IDEA, il peut être totalement intégré. Vous pouvez demander à IDEA d'utiliser sbt pour compiler en continu votre projet, et vice versa, vous pouvez utiliser sbt pour générer rapidement IDEA projets . Le dernier est extrêmement utile si vous êtes dans un cycle 'snapshot' avec en fonction d'autres de vos propres bibliothèques qui sont bousculées de la version mineure à la version mineure-fermez simplement le projet, mettez à jour la version dans le fichier de construction, réexécutez la tâche
gen-idea, et rouvrez le projet: mises à jour effectuées. - est fourni avec la plupart des tâches que vous aurez besoin (
compile,test,run,doc,publish-local,console) -- leconsoleest l'une des meilleures fonctionnalités. - certaines personnes mettent en évidence la fonctionnalité qui les dépendances peuvent être des référentiels source directement saisis à partir de GitHub. Je ne l'ai pas utilisé, donc je ne peux pas commenter ici.
Certaines personnes détestent sbt parce qu'il utilise Ivy pour la gestion des dépendances (Je ne peux pas commenter ses avantages et ses 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 Scala DSL au lieu de XML. Certaines personnes ont été déçues que le format de sbt ait changé de v0. 7 à v0. 10, mais évidemment, la migration ne vous affectera pas si vous commencer à partir de zéro.