SBT instead of Maven

On 15/12/2011 10:53, Edmondo Porcu wrote:
> Dear all,
> I am still using Maven for most of my projects but I might considering
> move to SBT.
>
> Can you help me understanding the benefits and the downsides of SBT
> compared to Maven?
>

SBT seems to be more considerated by Typesafe and other Scala
experienced dev, so you may find more help on Scala (and of course SBT)
mailing lists.
SBT is still a young product, and the last versions have been a major
switch compare to the 0.7.* ones. So up-to-date documentation, blog
posts and general resources would be rarer than for maven.
AFAIK, SBT allows to easily build plugins to do exactly what you want in
your build. It uses a Scala DSL in place of the pom. It manages really
well cross-compilation, if you need to compile your product for
different version of Scala, what maven can't do at all. It gives you an
interactive shell.

I, to, considered to migrate to SBT, but for what I'm doing, Maven works
great (at least, as great as it can), and the integration with Scala IDE
is OK thanks to Scala-m2e plugin (Thanks for that, David Bernard !). And
maven is ubiquitous in Java-land, its one less thing to teach to
newcomers ;)

Hope it helps,

If you have working builds for multiple projects, especially if you
have very nested parent poms, I would recommend staying with what
works.

IMO sbt is great - faster, easier configuration and programming model
(after you've gone crossed eyed for a while), and easy access to
continuous tests, sub projects consoles etc all from one warmed up jvm
and prompt.

Would I recommend to move a stable complicated Maven build over? - no.
If you are doing a new project with a new project hierarchy then its
more worth considering.

On Thu, Dec 15, 2011 at 10:53 AM, Edmondo Porcu wrote:
> Dear all,
> I am still using Maven for most of my projects but I might considering move
> to SBT.
>
> Can you help me understanding the benefits and the downsides of SBT compared
> to Maven?
>
>
> Best Regards
>
> Edmondo

On 2011, Dec 15, at 10:53 AM, Edmondo Porcu wrote:
> I am still using Maven for most of my projects but I might considering move to SBT.
>
> Can you help me understanding the benefits and the downsides of SBT compared to Maven?

The maven scala compiler plugin is about a factor five slower than its sbt-based counterpart because it recompiles most of your stuff incessantly. The way i understand this is that scala source files cause the creation of a bucketful of classes. Maven isnt able to sort out which needs to be updated, therefore it errs on the side of caution and recompiles more than it really needs to.

The maven workflow is hardcoded. SBT has a more flexible way of configuring how your builds should progress. But if you really need this, you may be overcomplicating things.

As far as I can tell, these are the only major reasons to swap. All the other ones seem to boil down to sbt being "nicer", for some value of "nice", but without a clearly defined business benefit.

We have been using maven the last eighteen months or so, and only just recently swapped to sbt. Our reason for changing was the test cycle speed increase. Our reason for not doing it until now is that sbt has been changing too much, it has been poorly documented in the past, and we had in-house maven knowledge from before. The migration was not without pain, but we have stuff like automated integration tests and other odd stuff that you might not.

Your mileage may vary. Hope this helps.

yours
Geir

Some thoughts on that:

While SBT certainly has some benefits - most of them mentioned by Francois - i think the most crucial thing against SBT is in its name: its a "SCALA" Build Tool.

So its nowhere existent in the not-so-cool-yet corporate world just considering Scala as a language.

I'd rather like people to build on existing platforms. Yes, mavens plugin model is flawed, but at least its properly sandboxed. Not so sure about SBT. (heck.. its a young project, offense!)

I just think that hyping SBT everywhere i see Scala leaves a behind a lot of great minds.

Lets face it.. cross compilation not possible in maven? probably ? But why blame the build platform (!) for Scala Compiler deficiency ? I love the progress scala has in making the language better/more powerful with every release. But the call for stabilization cannot be missed. And adopting a stable build platform like maven instead of growing its own child would help focussing.

just an idea. I already cracked some sleepless nights on why the hell does the world need SBT ? Feels like a selfish move by Scala-only heads. -sorry

Toni

On Thu, Dec 15, 2011 at 11:13 AM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:

If you have working builds for multiple projects, especially if you
have very nested parent poms, I would recommend staying with what
works.

IMO sbt is great - faster, easier configuration and programming model
(after you've gone crossed eyed for a while), and easy access to
continuous tests, sub projects consoles etc all from one warmed up jvm
and prompt.

Would I recommend to move a stable complicated Maven build over? - no.
 If you are doing a new project with a new project hierarchy then its
more worth considering.

On Thu, Dec 15, 2011 at 10:53 AM, Edmondo Porcu <edmondo [dot] porcu [at] gmail [dot] com> wrote:
> Dear all,
> I am still using Maven for most of my projects but I might considering move
> to SBT.
>
> Can you help me understanding the benefits and the downsides of SBT compared
> to Maven?
>
>
> Best Regards
>
> Edmondo

--

Toni Menzel Source

On Thu, Dec 15, 2011 at 11:33 AM, Toni Menzel wrote:
> Some thoughts on that:
>
> I just think that hyping SBT everywhere i see Scala leaves a behind a lot of
> great minds.

if sbt is receiving hype then its hopefully just the justified kind,
its really very excellent. You can also find a large number of
detractors out there which gives a nod to your statement.

Most blog posts don't set out to give balanced reviews, they are
blogging because someone is excited about what a technology offers
them. Same is true for all of those blog posts pushing Maven instead
of Ant.

>
> release. But the call for stabilization cannot be missed. And adopting a
> stable build platform like maven instead of growing its own child would help
> focussing.

I don't agree about growing its own child is a negative, but I do
think ignoring maven is a mistake, there is simply too much investment
in it.

> just an idea. I already cracked some sleepless nights on why the hell does
> the world need SBT ? Feels like a selfish move by Scala-only heads. -sorry

Does the world really need Ant, or Maven, when we have Make? Did we
really need Maven 3, when 2 and 1 existed before it?

Each of these tools was driven by perceived deficiencies in the
predecessor. Why should sbt or gradle or rake be any different in
trying to improve the developers experience. That seems like the very
definition of unselfish to me.

Hi,

for what it's worth, we used SBT to build Java-only projects way before we even
used Scala (for something else).
 

Toni Menzel wrote:

>  I already cracked some sleepless nights on why the hell does the world need
> SBT ? Feels like a selfish move by Scala-only heads. 
>

 
Why does the world need n+1 Linux distributions, programming languages, mobile
phones, types of apples, colors etc. etc. (yes, I realize the gross
overgeneralisation) I guess the answer is that different people prefer different
things. I personally won't touch Maven unless absolutely forced to. But then,
that's me and I don't call any Maven users (or even its authors) selfish for my
different preference. 
 
Kind regards
Andreas

On 2011, Dec 15, at 11:33 AM, Toni Menzel wrote:

While SBT certainly has some benefits - most of them mentioned by Francois - i think the most crucial thing against SBT is in its name: its a "SCALA" Build Tool.

Actually, it is a "simple build tool". It targets both java and scala.
yoursGeir

On 15/12/2011 11:32, Geir Hedemark wrote:
> On 2011, Dec 15, at 10:53 AM, Edmondo Porcu wrote:
>> I am still using Maven for most of my projects but I might considering move to SBT.
>>
>> Can you help me understanding the benefits and the downsides of SBT compared to Maven?
> The maven scala compiler plugin is about a factor five slower than its sbt-based counterpart because it recompiles most of your stuff incessantly. The way i understand this is that scala source files cause the creation of a bucketful of classes. Maven isnt able to sort out which needs to be updated, therefore it errs on the side of caution and recompiles more than it really needs to.
> [...

Just on that part: clearly, if you use only the command line (or
console), compilation time will drive you crazy with Maven, especially
in a non trivial multi-modules/multi-projects project. So for case, SBT
may be a real plus.

It is not the case if you use an IDE (Eclipse or IntelliJ at least),
because they each use some flavor of SBT incremental compilation and so
recompilation of depencies are well managed. So, you will pay the
maven-full-recompile-because-managing-dependencies-is-too-hard only when
you use the command line (so, it should be rarely, or in CI/packaging
task, for which you want a clean build in all cases).

Cheers,

On 12/15/2011 12:36 PM, Francois wrote:
>
> Just on that part: clearly, if you use only the command line (or console), compilation time will drive you crazy with Maven, especially in a non trivial
> multi-modules/multi-projects project. So for case, SBT may be a real plus.
>
> It is not the case if you use an IDE (Eclipse or IntelliJ at least), because they each use some flavor of SBT incremental compilation and so recompilation of depencies are
> well managed. So, you will pay the maven-full-recompile-because-managing-dependencies-is-too-hard only when you use the command line (so, it should be rarely, or in
> CI/packaging task, for which you want a clean build in all cases).

But... wouldn't you say that the dependency management is the primary function
of any build tool, the primary reason why you would use one in the first place,
as opposed to a simple shell script?

If it cannot do even that, well, let's say it's not so hot.

Stephan

The maven plugin has a pretty simplified view of dependencies.  I'm hoping to integrate SBT's analyzing compiler into a maven plugin at some point soon, but I have a lot more on my plate.
- Josh

On Thu, Dec 15, 2011 at 9:41 AM, Stephan Houben <stephanh [at] planet [dot] nl> wrote:

On 12/15/2011 12:36 PM, Francois wrote:

Just on that part: clearly, if you use only the command line (or console), compilation time will drive you crazy with Maven, especially in a non trivial
multi-modules/multi-projects project. So for case, SBT may be a real plus.

It is not the case if you use an IDE (Eclipse or IntelliJ at least), because they each use some flavor of SBT incremental compilation and so recompilation of depencies are
well managed. So, you will pay the maven-full-recompile-because-managing-dependencies-is-too-hard only when you use the command line (so, it should be rarely, or in
CI/packaging task, for which you want a clean build in all cases).

But... wouldn't you say that the dependency management is the primary function
of any build tool, the primary reason why you would use one in the first place,
as opposed to a simple shell script?

If it cannot do even that, well, let's say it's not so hot.

Stephan

On 15/12/2011 15:41, Stephan Houben wrote:

4EEA0718 [dot] 40608 [at] planet [dot] nl" type="cite">On 12/15/2011 12:36 PM, Francois wrote:

Just on that part: clearly, if you use only the command line (or console), compilation time will drive you crazy with Maven, especially in a non trivial
multi-modules/multi-projects project. So for case, SBT may be a real plus.

It is not the case if you use an IDE (Eclipse or IntelliJ at least), because they each use some flavor of SBT incremental compilation and so recompilation of depencies are
well managed. So, you will pay the maven-full-recompile-because-managing-dependencies-is-too-hard only when you use the command line (so, it should be rarely, or in
CI/packaging task, for which you want a clean build in all cases).

But... wouldn't you say that the dependency management is the primary function
of any build tool, the primary reason why you would use one in the first place,
as opposed to a simple shell script?

If it cannot do even that, well, let's say it's not so hot.

I may have been not really clear, and mixed to overloaded meaning of "dependency management":

• there is one dependency management for the library you want to use (what you have on you pom, or declare on sbt config file): that one is managed by (and only by) your build manager, independently of you use of an IDE.The fact that these dependencies are bring to your IDE depends of the integration of the build tool and the langage with the IDE. In the case of Scala and Maven, Scala-m2e allows Scala IDE to know about maven dependencies ; SBT use ivy under the hood, and the functionnality are roughtly the same than maven ones for that (even if Ivy seems to be far saner in a lot of behaviour than maven - but that something else ;)
  
• there is one dependency management about the class to generate again, when a class upon which they depends is modified. Say, if you have "class C" and "class A extends B", if B is modified, you want to recompile A, but not C. In that regard, maven is dumb (as much as "if one class was modified in module A and module B use module A, then I recompile all 1000 classes of B, even if only one of them is impacted by the modification in A"). SBT is really clever, and able to only incrementally recompile classes that really need to be - and so, the huge compilation boost you see. So, you will have that boost if you use "continuous compilation" with SBT console, or if you use an IDE that relies on SBT for the incremental compilation part - what does Scala IDE for eclipse, and I believe IntelliJ's Scala plugin.
  

Hope it's a little clearer, and sorry for the confusion !

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

I have tried SBT and now I am back to Maven.

Reasons:
1) SBT has uncountable number of versions.
2) Each version of SBT has small amount of plugins. A plugin for one version does not work for another. The 'license' plugin is not available for any version at all.
3) You have to learn yet another DSL which is not the same from one version to another

I think I will look at it again when they announce 1.0 and when there will be the commitment to support the backwards compatibility.

-
Andrey

On Thu, Dec 15, 2011 at 15:10, Andrey Somov wrote:
> I have tried SBT and now I am back to Maven.
>
> Reasons:
> 1) SBT has uncountable number of versions.
> 2) Each version of SBT has small amount of plugins. A plugin for one version
> does not work for another. The 'license' plugin is not available for any
> version at all.
> 3) You have to learn yet another DSL which is not the same from one version
> to another
>
> I think I will look at it again when they announce 1.0 and when there will
> be the commitment to support the backwards compatibility.

This is a gross misrepresentation. SBT has a number of versions (far
less than Maven), which are essentially compatible. There's one
exception: everything up to 0.7.7, and everything after it. So, for
practical purposes, SBT has two versions.

SBT does suffer from binary compatibility issues. We're working on a solution for that.
I'd argue, you should use the best build tool for your problem.  I use a *lot* of SBT but I still maintain the maven-scala-plugin.   Right now Maven is still the best build tool for eclipse IDE development.  They specifically set out to be the best in this area.
SBT is still young and has some hardening to do.  However, as it is I've found it *far* easier to develop in.   I have some rather advanced builds that do things that blow me away compared to what I used to do in Maven.   The learning curve may be steeper, but it's certainly worth it.
- Josh

On Thu, Dec 15, 2011 at 1:34 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:

On Thu, Dec 15, 2011 at 15:10, Andrey Somov <trophybase [at] googlemail [dot] com> wrote:
> I have tried SBT and now I am back to Maven.
>
> Reasons:
> 1) SBT has uncountable number of versions.
> 2) Each version of SBT has small amount of plugins. A plugin for one version
> does not work for another. The 'license' plugin is not available for any
> version at all.
> 3) You have to learn yet another DSL which is not the same from one version
> to another
>
> I think I will look at it again when they announce 1.0 and when there will
> be the commitment to support the backwards compatibility.

This is a gross misrepresentation. SBT has a number of versions (far
less than Maven), which are essentially compatible. There's one
exception: everything up to 0.7.7, and everything after it. So, for
practical purposes, SBT has two versions.


--
Daniel C. Sobral

I travel to the future all the time.

Currently I'm using sbt only for personal projects (mostly very
simple).

Before considering using it instead of maven for work projects I need
to be sure that it integrates flawlessly with familiar toolchain.
E.g. does it work with bamboo\jenkins\teamcity\sonar? Does it play
nicely with IDEA (it pretty much does, but there are rough edges)?
Can I achieve the same functionality available with maven plugins and
ant tasks (at least the most popular, e.g. filtering, versions plugin,
release plugin, contrib, ssh)?

Currently this information is missing or sparse.

Thanks, Oleg.

Can you help me understanding the benefits and the downsides of SBT compared to Maven?

We are using both Maven and SBT. Maven is used on our primary codebase while we have begun testing out SBT on newer projects. We assessed whether to move our largest project over to SBT and decided against it. Basically, it works as is and we have little pain maintaing it and there was no reason to open up a new can of worms. I have been working on many of the new projects that use SBT and am enjoying it for the most part. I've found that as a result I'm spending more time in the SBT console than the IDE to do things like run tests and compile. Having "~test-only test.you.are.currently.workingOn" is awesome from a productivity perspective. However, its still obvious that SBT is not yet as mature. v0.11.1 still crashes on me frequently with OOM errors (no matter how high I put any JVM setting). 
Overall my 2c is: if your green-fielding a project and its not "hyper-mission critical" (e.g. needs to be working tomorrow and you are attempting to minimize all possible risks) then give SBT a go, if you have a project working with Maven already just leave it. If your green-fielded project is "hyper-mission critical" use what your used to and you can always move it over and learn migration lessons later. 
Jordan

On Thu, Dec 15, 2011 at 5:33 AM, Toni Menzel <tonit [dot] com [at] googlemail [dot] com> wrote:

Lets face it.. cross compilation not possible in maven? probably ? But why blame the build platform (!) for Scala Compiler deficiency ? I love the progress scala has in making the language better/more powerful with every release. But the call for stabilization cannot be missed. And adopting a stable build platform like maven instead of growing its own child would help focussing.

No ones blaming the build platform. But if sbt work better for cross-compiling, then use it. Making life harder for yourself is not going to make scala as backward as compatible as Java. And it shouldn't be. It's just a library after all (from a binary build perspective).

On Thu, Dec 15, 2011 at 5:32 AM, Geir Hedemark <geir [dot] hedemark [at] gmail [dot] com> wrote:

Our reason for not doing it until now is that sbt has been changing too much

I think that's a common perception that's not really deserved. Sbt changed once, dramatically, a good while ago, after 0.7.x .

it has been poorly documented in the past

That may be true but now it's very well documented --- it has a very well written and comprehensive walkthrough on the github wiki.  

On Friday, 16. December 2011 at 08:11, Naftoli Gugenheim wrote:

it has been poorly documented in the past

That may be true but now it's very well documented --- it has a very well written and comprehensive walkthrough on the github wiki.

up to the point where you want to start writing tasks or plugins. there isno documentation on sbt's API.
https://github.com/harrah/xsbt/wiki/Getting-Started-Custom-Settings says

"sbt has some utility libraries and convenience functions, in particular you can often use the convenient APIs in IO to manipulate files and directories."

almost no scaladoc there, no "getting started" doc or similar, also no intro to the path dsl...

On 2011, Dec 15, at 10:01 PM, OlegYch wrote:
> to be sure that it integrates flawlessly with familiar toolchain.
> E.g. does it work with bamboo\jenkins\teamcity\sonar? Does it play

jenkins works fine. We set it up this week, and it didn't even take that long.

We don't use teamcity here, and I didn't think sonar had scala capabilities?

yours
Geir

On 2011, Dec 16, at 8:11 AM, Naftoli Gugenheim wrote:

Our reason for not doing it until now is that sbt has been changing too much

I think that's a common perception that's not really deserved. Sbt changed once, dramatically, a good while ago, after 0.7.x .

Your mileage may vary. This was our opinion.
We think what we think because the interfaces of sbt may have been static, but there have been changes in the semantics of how they worked. A while ago we had to manually exclude a number of dependencies because of an oddity in how ivy looked up transitive dependencies. At some point, this behavior changed, and then we could remove the workaround.
Right now (0.11.1) we have to manually go off and fix our local dependency cache because it contains a .pom file, but no matching jar. sbt 0.11.2 has fixed that.
All of this manual tweaking takes time, and until now we were sent into tweak mode for the simplest stuff. We prefer to have only a limited number of tools that send us into tweak mode, which is why we have stuck to maven until now because we already have a working tweak base for it.

it has been poorly documented in the past

That may be true but now it's very well documented --- it has a very well written and comprehensive walkthrough on the github wiki.

I don't agree that sbt is "very well documented". I still can't figure out what the model for the test process lifecycle is from the documentation. We create singleton objects that somehow live through test runs - slightly interesting behavior the first time you run across it. There is an "integrationtest" class in sbt, but very little information on integration testing in the docs last time I checked.
The same applied, and to some extent still applies, to maven as well.
My ten cents.
yoursGeir

On Fri, Dec 16, 2011 at 2:27 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

On Friday, 16. December 2011 at 08:11, Naftoli Gugenheim wrote:

it has been poorly documented in the past

That may be true but now it's very well documented --- it has a very well written and comprehensive walkthrough on the github wiki.

up to the point where you want to start writing tasks or plugins. there is no documentation on sbt's API.
https://github.com/harrah/xsbt/wiki/Getting-Started-Custom-Settings says

"sbt has some utility libraries and convenience functions, in particular you can often use the convenient APIs in IO to manipulate files and directories."

almost no scaladoc there, no "getting started" doc or similar, also no intro to the path dsl...

Fair enough, although I didn't think the discussion was comparing writing plugins for maven vs. for sbt. Although sbt may lack certain plugins (necessitating writing them) that maven already has...

We use Maven 2 and 3. I consider them as one version because everything works transparently for us. At least we do not have compatibility issues.

When I get SBT projects from github, some of them require 0.10.x, some 0.7.x, some 0.11.x. Even the last digit matters !!!

When I have the Maven script I can blindly say 'mvn test' and it always works.

If there is no problem with versions why there is an application which dynamically finds the appropriate SBT version ?

-
Andrey

SBT decided not to go 1.0 until it was ready, hence the 0.7 -> 0.10 change. 
Maven also had such a change form 1.x -> 2.x where it broke *everything*.  If maven had stayed at its 1.x state, I'd never have used it.  As it is, the 2.x change was great and by the time they hit 3.x they had a larger team and focused on backwards compatibility with 3.x.
I think you need to compare apples to apples.   SBT is nowhere near a 3.x release...
- Josh

On Fri, Dec 16, 2011 at 6:17 AM, Andrey Somov <trophybase [at] googlemail [dot] com> wrote:

We use Maven 2 and 3. I consider them as one version because everything works transparently for us. At least we do not have compatibility issues.

When I get SBT projects from github, some of them require 0.10.x, some 0.7.x, some 0.11.x. Even the last digit matters !!!

When I have the Maven script I can blindly say 'mvn test' and it always works.

If there is no problem with versions why there is an application which dynamically finds the appropriate SBT version ?

-
Andrey