Suereth J.D. - sbt in Action

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

2016 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 761Shelter Island, NY 11964

Development editor: Jennifer StoutTechnical development editors: Patrick Touhey, Matt MomontCopyeditors: Tiffany Taylor, Linda RecktenwaldProofreader: Melody DolabTechnical proofreader: Thomas LockneyTypesetter: Dottie MarsicoCover designer: Marija Tudor

ISBN 9781617291272

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 EBM 20 19 18 17 16 15

Its 2012-ish and Im in the middle of bootstrapping Typesafe, the company behind Scala. I get a call from Manning about more book ideas for Scala. At the time, I was working on one of the least understood and most important tools in the Scala ecosystem: sbt. sbt was a build tool that had some rough edges, but was amazingly powerful and elegant in its core idioms. After a quick chat with Michael Stephens at Manning, we decided to put a proposal together and see if we could find a second author. While I really wanted to see an sbt book, as the community desperately needed one, at the time my commitments at home and work were too much for a new book. This lead to us eventually finding Matthew as a second author, and Im very glad we did. Matthew has been great to work with and brings his own unique humor that I very much appreciated throughout the book writing process.

For some reason, I tend to wind up as the build guy for my day job. This inevitably happens due to two flaws in my personality:

• A desire to understand everything I use
• A desire to improve my daily workflow

At Typesafe, this meant I was thrown into using sbt. At the time I was a Maven guy, having fallen in love with the notional simplicity of lifecycles, plugins, and declarative builds. In fact, I had forks of most major Maven plugins at my company to tweak/work around issues we discovered. When I first picked up sbt, I didnt like it.

The documentation at the time was sparse, and the idioms for the build were by far a lot different from what I was used to. However, as I started diving in, asking lots of questions of Mark Harrah, my coworker and the inventor of sbt, I found something beautiful underneath the rough exterior. sbt had (whether on purpose or by accident) turned into an automation delivery vehicle for your development experience.

By this, I mean that sbt allowed me to control and tune my build for my most common tasks, with an emphasis on interaction. In other words, sbt was not a one shot build; it was something you ran like an IDE, and it made coding Scala so much better than any other IDE at the time.

Im so glad we were able to write this book to show you the vision of what I saw in this little tool. It still has some rough edges here and there, but I hope youll see the beauty and what I consider the future of build tools.

J OSH S UERETH

When Manning approached me about helping out with a book about sbt, I jumped at the chance. Id contacted Manning to help with another book, and they suggested that I help with this one. I knew Josh through the Scala community, and I knew his reputation, so working with him would be great.

Ive always been interested in code quality and software that helps me develop more easily. I like Larry Walls idea of being productively lazy. Ive contributed to a number of open source projects to help with quality, such as Scala-IDE, JUnit, and most notably Scalastyle, the style checker for Scala that I wrote because I hate having to remember to put a copyright header on each source file.

The first real build tool I used was Make. Before that it was simple shell scripts. Make is great as long as you dont have to build on multiple platforms. For me, the problems with Make are summed up in one project: Perl. There isnt one makefile for Perl; it is generated by a 25,000-line shell script according to your systems capabilities. Now, admittedly, Perl is built for a huge number of systems, but 25,000 lines to create a makefile? Really?

When I saw Apache Ant for the first time, it was a revelation. By abstracting out the differences between operating systems to the JVM, you didnt need to worry if your system was being built on Microsoft Windows or Linux. And then came Maven. Maven took the abstraction even furtheryou said This is a Java project; build it rather than I want to compile my Java. But Maven was still a bit clunky for all of the custom tasks we had as part of our build.

Then I started using Scala. Some of the Scala developers used sbt, and I wanted to know more. I immediately saw the usefulness of some of the things that sbt was doing. First, the ~ operator has more rapid feedback. I loved saving a file and having my sbt tell me my unit tests had failed. What could be better than something automatically telling you that you had screwed up? Second, I loved the fact that the code was written in a statically typed languageI didnt have to wait two hours for my build to fail with what would have been a compilation error.

We started writing the book in January 2013, and the result of that work is before you now. I hope you enjoy it.

I feel that the importance of build tools in a project is often underestimated. A good build tool will help you with your project. A bad build tool will get in your way.

M ATTHEW F ARWELL

When we signed up to write this book, we didnt know how much effort it would require, or how long it would take. We started in 2013, and not only did we have to write the book, but sbt was changing underneath us as we wrote! It was Joshs second book, so he had some idea, but Matthew had no idea. Without the assistance of many people, this book would definitely not be in your hands or on your screen right now. Its much more likely that we would still be working on it.

From day one of the project, help has poured in, and all of it has been not only appreciated but essential. If weve forgotten anyone, please accept our sincere apologies. In no particular order, wed like to thank the following people for their work and support.