There exists a very popular build tool: Maven. Even I use it. It has advantages:
- There are plugins for everything!
- There is a lot of information and knowledgeable people!
- It integrates well with the IDEs!
- It is configured in Scala (a little less with 0.10, but still kinda). This is shorter and more powerful than Maven’s XML.
- It supports continuous compilation.
- It supports continuous testing.
To gain advantages of sbt, one has to abandon Maven completely, and loose all its advantages. For legacy projects, Maven POM has to be ported to sbt, which is likely non-trivial, and not always even possible. Is the pain worth the gain?
I do not want to have to rewrite all my POMs for sbt so that they become shorter; I can deal with them the way they are.
Even for new projects, I’d rather write a POM and not a sbt configuration: I can then use existing Maven plugins instead trying to find, write or commission an sbt one.
More powerful configuration.
I think Maven 3 will bring more power, but I am happy with the power of Maven 2. I do not need my build system to be Turing-complete.
Mark Harrah himself said that super-powerful settings mechanisms of sbt are not the goal of the project. The goal is to handle quick, continuous compilation.
It would be nice to make the build time shorter. Scala distribution provides compiler as a server for this purpose (I do not know how to use it from within my IDE)…
It would be nice to make deployment time shorter for web applications. But sbt does not do it. One has to use frameworks like Play and products like JRebel for that - which can be done with or without sbt!
I am not (yet?) into Test Driven Development, so I do not miss continuous testing :)
Also, Scala plugin for Maven supports continuous compilation and testing. Is sbt’s support any better? I heard from a colleague that sbt supports multi-project continuous compilation and Maven plugin does not. Can the plugin’s be improved?
It seems logical that features needed for continuous/incremental compilation should be packaged in the Scala compiler itself. Indeed, according to Mark, incremental compilation feature that was present in the Scala compiler is based on early versions of his sbt work. With advances in sbt that code rotted, and the feature has been removed!
I think that was a step in the wrong direction.
Typesafe (the Scala company) seems to be pushing sbt: it is part of the Typesafe Stack. When I asked about Maven compatibility, I was told than Typesafe “is not a Maven company”, and that I should search among sbt plugins written by the community.
As is clear from the above, I am not ready to abandon Maven for sbt. And I am sure I am not alone in that.
I think that Typesafe should refine its Maven story. You can’t just say “we are not a Maven company” if you are trying to penetrate enterprise market, where Maven is entrenched.
Advantages of sbt should be available in Maven-based builds. Writing a POM with sbt’s “make-pom” does not cut it. Can sbt read the POM? Even in the presence of additional setting tweaks in sbt?
Can sbt be packaged as a Maven plugin? Or, existing Maven Scala plugin enhanced?
Can continuous compilation support be moved (back) into Scala compiler? Continuous compilation could then be used by multiple tools, including Maven, and we all will be happier :)
Update October 2012: It seems that I am not the only one not drinking the sbt Kool-Aid. It also seems that Typesafe got at least part of the message: they made Zinc, a stand-alone version of the sbt’s incremental compiler, and scala-maven-plugin supports it!
simplemath Wednesday, February 22, 2012 4:33:00 AM
For legacy projects, Maven POM has to be ported to sbt, which is likely non-trivial, and not always even possible.
Not at all. You can say to sbt that there is pom file and you want to reuse it by adding
Leonid Dubinsky Wednesday, February 22, 2012 3:33:00 PM
externalPom() is documented at https://github.com/harrah/xsbt/wiki/Library-Management thusly:
Maven pom (dependencies only) externalPom() or externalPom(baseDirectory(_ / “custom-name.xml”))
It seems that aside from dependencies, the POM will have to be duplicated in sbt to make sure that artifacts produced by sbt and Maven are exactly the same. It is also not clear that sbt will honor repository declarations - or dependencies that involve properties.