Avantages et inconvénients de l'utilisation de sbt vs maven dans le projet Scala [fermé]
138
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?
J'ai fait la transition de Maven à Gradle pour les projets Scala, en raison de son support supérieur pour les builds multi-modules. L' expérience de Twitter avec SBT est décrite par eux comme une "douleur aveuglante" et ils essaient de s'en éloigner (avec Maven comme une étape dans ce processus).
Ben Manes
24
Une autre question fermée cool ...
Cedric H.23
14
Tellement de bonnes questions que je vois qui sont juste fermées; Je ne sais pas qui donne à ces personnes le pouvoir de décider arbitrairement de clore une question ou non. Je ne fais même pas attention à savoir s'ils sont proches ou plus.
user1888243
2
Se mettre d'accord. Heureusement, nous avons 2 réponses avant que cette question ne soit close. Pauvre pour ceux qui votent pour clore cette question ...
hqt
Réponses:
83
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 pour lancer une construction, bien sûr, mais nous avons un tas d'autres informations provenant de Maven et que nous voulons entrer dans CI. C'est à peu près la seule raison pour laquelle je peux penser d'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 la compilation incrémentielle, ce qui est énorme. La possibilité de démarrer un shell à l'intérieur de votre projet, ce qui est également excellent.
ScalaMock ne fonctionne qu'avec SBT, et vous allez probablement vouloir l'utiliser plutôt qu'une bibliothèque de simulation Java. En plus de ça, c'est beaucoup plus facile d'étendre SBT puisque vous pouvez écrire du code scala complet dans le fichier de construction, vous n'avez donc pas à passer par toute la rigueur de l'écriture d'un Mojo.
En bref, utilisez simplement SBT sauf si vous avez vraiment besoin d'une intégration étroite dans votre serveur CI.
Je ne suis pas en désaccord avec tout ce qui précède, mais je voulais juste souligner que je suis en train d'écrire ScalaMock 3 , dont l'un des principaux objectifs est de faciliter la prise en charge d'autres systèmes de construction.
Paul Butcher
1
Juste pour être complet, il convient de mentionner que ScalaMock 2 fonctionne très bien avec n'importe quel système de construction (c'est juste un pot) tant que vous n'avez pas besoin d'utiliser des simulations générées (c'est-à-dire tant que vous n'avez besoin que de simuler des traits / interfaces ).
pourquoi n'ont-ils pas simplement écrit une compilation incrémentielle pour maven? À mon humble avis, sbt est un exemple d'arche d'un syndrome du NIH non traité ...
Cpt. Senkfuss
1
Pourquoi des problèmes de CI dus à SBT?
Daniel
21
La question risque de ne générer que de nombreuses opinions; il serait préférable d'avoir une liste claire des exigences ou une description de votre environnement, des connaissances antérieures, etc.
Mes 2c sont: optez pour 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 tant que vous n'avez pas de dépendances)
il est couramment utilisé dans les projets open source Scala. Vous pouvez facilement en apprendre davantage sur la configuration en jetant un œil aux projets d'autres personnes. De plus, de nombreux projets supposent que vous utilisez sbt et vous fournissent des instructions de copier-coller prêtes à 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 permanence votre projet, et vice versa, vous pouvez utiliser sbt pour générer rapidement des projets IDEA . Le dernier est extrêmement utile si vous êtes dans un cycle `` instantané '' avec en fonction d'autres de vos propres bibliothèques qui sont passées de la version mineure à la version mineure - fermez simplement le projet, mettez à jour la version dans le fichier de construction, réexécutez legen-idea tâche, et rouvrez le projet: mises à jour effectuées.
est livré prêt avec la plupart des tâches que vous aurez besoin ( compile, test, run, doc, publish-local, console) - le consoleest l' une des meilleures caractéristiques.
certaines personnes soulignent la fonctionnalité selon laquelle les dépendances peuvent être des référentiels sources directement récupérés sur GitHub. Je ne l'ai pas utilisé, je ne peux donc pas commenter ici.
Certaines personnes détestent sbt car 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, ce n'est pas un 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 soit passé de la v0.7 à la v0.10, mais évidemment, la migration ne vous affectera pas si vous partez de zéro.
Je déteste sbt parce que son abus d'opérateurs symboliques et certaines décisions stupides, telles que les formats de définition .sbt et .scala, mais les placent à des endroits différents, et les déclarations en .sbt doivent être séparées par au moins une ligne vide, etc. Les documents de sbt s'améliorent mais pas assez pour le moment. Ce qui me manque le plus, ce sont des exemples de fichiers .sbt / .scala complets (du minimum au complexe du monde réel) expliqués ligne par ligne, couvrant toutes les fonctionnalités de sbt. Cela dit, j'utilise sbt tous les jours car Maven craint beaucoup plus.
xiefei
6
Dommage que cette question soit close, je suis sûr qu'il y a aussi des différences factuelles: par exemple cet extrait du livre de Manning sur SBT: "S'il y a des dépendances entre les objectifs Maven (disons qu'un objectif produit un fichier qui est consommé par un autre) alors vous ne pouvez pas paralléliser votre build avec Maven. Avec sbt, vous devez spécifier une dépendance explicite entre les tâches. Cela permet à sbt d'exécuter des tâches en parallèle PAR DEFAUT. Si la tâche A dépend de B, et C dépend également de B, alors sbt exécute la tâche B, puis exécute A et C en parallèle. " J'espère que ce commentaire aidera certains lecteurs.
jhegedus
19
J'ai trouvé ce fil très utile. Je pense très souvent que les modérateurs de Stackoverflow ferment les discussions avec trop d'empressement. Qui se soucie s'ils sont "hors sujet" alors qu'ils sont très souvent exactement ce que les utilisateurs recherchent (et trouvent par le biais de recherches sur le Web). C'est comme si les mods Stackoverflow essayaient de recréer intentionnellement xkcd 979 .
Ville
3
@Ville Mes pensées aussi. Le vote négatif, l'édition et la clôture sont devenus trop agressifs.
ankush981
2
Pour quiconque regarde cela maintenant, les plaintes de @ xiefei ont été traitées. SBT a abandonné de nombreux opérateurs / syntaxes plus personnalisés, et les instructions dans les fichiers / sbt n'ont plus besoin de séparations d'espaces.
Réponses:
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 pour lancer une construction, bien sûr, mais nous avons un tas d'autres informations provenant de Maven et que nous voulons entrer dans CI. C'est à peu près la seule raison pour laquelle je peux penser d'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 la compilation incrémentielle, ce qui est énorme. La possibilité de démarrer un shell à l'intérieur de votre projet, ce qui est également excellent.
ScalaMock ne fonctionne qu'avec SBT, et vous allez probablement vouloir l'utiliser plutôt qu'une bibliothèque de simulation Java. En plus de ça, c'est beaucoup plus facile d'étendre SBT puisque vous pouvez écrire du code scala complet dans le fichier de construction, vous n'avez donc pas à passer par toute la rigueur de l'écriture d'un Mojo.
En bref, utilisez simplement SBT sauf si vous avez vraiment besoin d'une intégration étroite dans votre serveur CI.
la source
La question risque de ne générer que de nombreuses opinions; il serait préférable d'avoir une liste claire des exigences ou une description de votre environnement, des 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: optez pour sbt si vous n'avez pas d'exigences spécifiques
gen-ideatâche, et rouvrez le projet: mises à jour effectuées.compile,test,run,doc,publish-local,console) - leconsoleest l' une des meilleures caractéristiques.Certaines personnes détestent sbt car 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, ce n'est pas un 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 soit passé de la v0.7 à la v0.10, mais évidemment, la migration ne vous affectera pas si vous partez de zéro.
la source