David en a parlé, il est passé sur sbt et pourtant il a l'air de regretter
maven ;)

Je n'ai pas le même background que David (j'ai juste dev un plugin sbt et
un peu bricolé comme tout le monde avec maven), mais j'avoue être partagé
sur sbt.
Certes il y a des chose très sympa dans sbt : la console, l'exécution en
continue, une simplicité relative etc... (je vous laisse compléter)
En revanche des qu'il faut un peu mettre les mains dedans c'est franchement
pas clair (pour le coup j'avoue que j'ai un peu fait du dev pifometrique).

De l'autre coté, maven est plutôt bien documenté, relativement simple mais
fastidieux (xml n'y est pas pour rien).

Du coup j'aimerais votre avis sur sbt pro/cons vs maven. Et que penser de
gradle et buildr ?

Pour répondre le plus simplement possible, avec bien sûr seulement mon avis
:
entre sbt et maven, du moins si tu es en scala, autant aller sur sbt tu
auras plus d'avantages (certains que tu as évoqués, et la simplicité de
mise en place en plus),
surtout que dans les deux cas si tu n'as pas un projet "vanille" la douleur
risque d'être très importante pour mettre en place le tout correctement.

Pour moi c'est là que partir sur gradle et buildr est une bonne alternative
à souffrir avec sbt/maven ou ant.
En somme,
pour moi sbt est plus simple et rapide, que ce soit au niveau mise en place
ou rapidité pour des projets "usuels", voire des projets multi-modules bien
segmentés.
et gradle/buildr pour des projets un peu custom avec des specificités
(genre des jar de jar...).

++

Le 25 septembre 2012 09:31, Alexis Agahi <alexis.ag...@gmail.com> a écrit :

Je détaillerai plus tard mon avis du sbt/maven, mais c'est la boite ou je
bosse qui est passé cette été de sbt 0.7 à sbt 0.11 (avec grosse refonte de
nos process de build, packaging, decoupage des projets, ...).
Pour info, nous avons beaucoup de galères avec le cache ivy (nous avons de
script pour vider les caches,...), nous sommes meme passe de nexus à
artifactory pour gérer les plugin sbt dans des repo au "format" ivy.

2012/9/25 Olivier Girardot <ssab...@gmail.com>

Faire du scala avec gradle est aussi sur ma todo list. sbt semble être bien
encré dans l'ecosystème scala, mais je pense qu'il y a de la place pour un
concurrent.

En outre, la communauté Clojure n'agonise pas sur le choix car ils ont un
outil de build (leiningen) qui marche bien. Leiningen offre un DSL Clojure
par dessus Maven et les goodies habituels: REPL, compilation & tests en
continu. Il y a même un plugin scala, mais je ne l'ai pas encore testé.

Le 25/09/2012 09:31, Alexis Agahi a écrit :

Notre cas pour Rudder : on utilise Maven. C'est historique (je vais
raconter), mais même si je commençais un projet aujourd'hui, je ne suis
pas sûr sûr que je partirais sur SBT. Enfin, si pour moi, oui. Pour un
projet "full stack typesafe", aussi, sûrement. Mais sinon, je me
poserais la question. Remarquez que c'est une nette évolution, il y a
6/8 mois, je ne serais pas parti du tout sur SBT. Depuis, Typesafe a
décidé de migrer le build de Scala sur SBT, ils vont bien être obligé de
l'utiliser en interne aussi...

Bref. Historiquement, à son début en 2009, Rudder devait être un projet
Java (avec peut-être du Scala). Et donc pas trop de question à se poser:
la quantité d'emmerdes apportés par Maven est contrebalancé par la
quantité de gens qui les ont, et on n'avait pas envie de mettre en plus
du ruby ou du Grails dans notre build (personne chez nous n'a d'affinité
particulière pour ses langages, plutôt le contraire). Et SBT semblait
être une évolution plus probable en tant qu'alternative.
Puis on est passé en full Scala (disons, juste après le début du projet
:), et on s'est posé la question: SBT n'était pas assez mature à notre
gout, avec un futur pas clair (une seule personne sur le projet...),
pour un truc aussi critique et casse-bonbon que le build => on est resté
sur Maven.
La suite nous donne plutôt raison, avec de grosses évolutions de SBT qui
semble casser tous les trois matins (alors que maven casse tous les
jours, mais de manière attendue :). Et le coût du changement est de plus
en plus élève: notre build fonctionne assez bien, il est intégré à plein
d'outils (CI, tests, Eclipse, etc) alors que le gain de SBT n'est pas
clair... Bref, à part pour être hype et pouvoir dire je n'utilise plus
cette daube de Maven, j'utilise cette daube de Ivy à la place... Donc
voilà, on n'utilise pas SBT.
On changera peut-être un jour, dès que SBT/Eclipse seront bien intégrés
(ça commence doucement), si on a un besoin spécifique difficile à faire
en Maven, si SBT mature encore un peu, si on a un gars avec de grosses
compétences sur l'outil, ou si on a plein d'argent à dépenser pour être
hype :)

Cheers,

--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

J'avoue, je suis un pervers: j'ai commencé à essayer de builder des
projets Java avec sbt !

Je trouve les concepts de sbt plutôt mieux foutus que maven, et je
n'ai pas souffert avec ivy car mon degré d'utilisation a été faible,
je suppose. En particulier, j'aime bien la souplesse de structure
qu'offre sbt, et le fait que si je fais du code de build spécifique,
c'est dans la code line puisque c'est un projet sbt !

L'idée que tente d'implémenter sbt, il me semble, c'est d'arrêter de
faire semblant de croire que le build peut être "one size fits all",
proposer une boîte à outils, quelques trucs pré-packagés bien foutus.
Et à la différence de ant, il ne fait pas semblant de croire qu'on
peut coder (et maintenir du code) efficacement en XML. Evidemment,
c'est encore un peu brut mais j'ai été séduit par la nouvelle
approche, je dois dire. Dommage que je n'ai pas que ça à faire...

Et pourtant, je suis un utilisateur de longue date de maven !

Arnaud

Pour l'instant j'ai surtout utilisé sbt a travers play20

C'est assez douloureux :/ mais il semble que ce soit en partie du a play

--
jean
Le 28 sept. 2012 17:54, "Arnaud Bailly" <arnaud.oq...@gmail.com> a écrit :