When the original version was published on 06/19/2011, the motive for writing this guide was to aid the effort of moving people over to sbt 0.10 from 0.7, inspired by Mark’s sbt 0.10 demos that I was able to see live (first at northeast scala, and second at scala days 2011). At the time, the plugins were considered to be a major roadblock to the migration, since build users can’t move to 0.10 without the plugins. So my strategy was to port the plugins myself if they weren’t there, ask questions on the mailing list when I get stuck, and write up the results. I’ve gotten many positive feedbacks, and it’s helped people get on to 0.10. However, as it turns out, my understanding of sbt 0.10 wasn’t always complete, and downright wrong and misleading at times. I take responsibility of my writing. Instead of leaving old contents in, I’ve decided to push it into github, make a new version and move on. The most up-to-date knowledge of writing plugins is compiled in Plugins Best Practices written mostly by Brian and Josh, and a tiny section by me.
Let’s talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course.
scripted test framework
sbt comes with scripted test framework, which let’s you script a build scenario. It was written to test sbt itself on complex scenarios such as change detection and partial compilation:
I wish there was a common super trait for various future implementations in the standard library, so I can express the concept without tying the code to a specific platform stack. I am not sure if there are others who feel the same, but I think it would be useful for library authors. That’s my motivation of writing sff4s.
what is future?
You’ve probably come across the notion before but let’s go over it quickly. A future value (also known as promise) represents an incomplete calculation.
I’ve tried other IDEs for Scala, but always ended up going back to TextMate. As I am getting on the IntelliJ IDEA wagon, I’ve made a Twilight theme to make the ride smoother.
Ultimately, the users of scalaxb are interested the real problems that the entity objects express, not how they persist into XML. That’s why I knew I eventually had to vacate the singleton/companion object of the case class to implement the data binding. Until recently it has been generating the data binding implementation as follows:
Once you use any technology to a significant extent, you understand its strength and shortcomings. I’ve probably written tens of thousands of lines of code in Delphi or C++, Java and C# too to some extent. I’ve depended on those languages, but gripe about them too. The new language obviously has the advantage of just being new. Since I haven’t written anything significant in Scala besides Tetris, I haven’t hit the shortcomings yet.
