Getting Involved

There are many opportunities for getting involved in sbt 0.9.x development. Some are listed here. They are only suggestions, though. If there is something else you'd like to work on, send an email to the list if you want to discuss it or submit a pull request on github if you've already implemented it. The source code is on github, in the 0.9 branch of the xsbt repository.


  1. The main design task remaining is determining how sbt 0.9.x will be configured by users. This is the highest priority work right now. In 0.7.4, almost every possible setting can be changed by overriding a single method. The advantage is that most things can be changed by adding a line to the project definition. The disadvantage is a proliferation of methods and difficulty determining what that line should be. Perhaps the current way is the best way. Perhaps there is a better way. This task is open to discussion and prototyping. See main/DefaultProject.scala for how the basic tasks are currently wired up for 0.9. Some related aspects to this are:
    1. Reintegrate properties, replace with settings, some combination, or something new. Basically, I'd like to see a general mechanism that includes per-task configuration. For example, it would be integrated with logging to configure logging levels per-project, per-task, and screen vs. persisted.
    2. Reintegrate 'doc', 'console', 'run', 'test'. The backends for these all exist. What is open is integrating them according to whatever configuration scheme is determined.
  2. Build/release management. There are opportunities to automate more of sbt's build, especially for releases. For example, the launcher is currently uploaded manually. There are some related open bugs such as publishing source and javadoc artifacts for sbt. Another project management issue is that the wiki pages for Google Code are dumped into a single folder. It is not easy to organize the documentation better and publishing multiple versions (show 0.7.4 documentation by default, have 0.9.x in progress) is not practical.
  3. Add support for remote projects. The new external project support should make it easy to add support not only for external projects on the filesystem, but also for projects obtained remotely. This might include projects checked out using git or svn or a zip downloaded and extracted from the internet. A simple, initial version should be a relatively self-contained and small project. Loading is done in main/MultiProject.scala. Instead of a File representing an external project, a URL or custom datatype could be used.
  4. Compilation now produces an Analysis, a data structure representing the relationships between sources and binaries and the API of sources. As a start, the previous graph-src and graph-pkg could be reimplemented to operate on this Analysis instance.
  5. Dependency management. There is always lots to learn and do here. As a start, publishing needs reintegration. 'update' and 'publish' should only perform actions if the inputs have changed. Selecting external pom.xml or ivy.xml should be explicit (no more auto-detection, just default to inline). The API for dependency construction should allow specifying exclusions. Ivy related code is in the ivy subproject.
  6. Clean up Path, PathFinder, and other I/O code. There is an awkward balance between Path and File. More APIs in 0.9 just accept File. There are bidirectional implicit conversions between Path and File. Should Path just be a type-class operating on File? Should Path be similar to the way it currently is, but replace File everywhere? Should we not modify the current code too much and wait for the Scala I/O library?
  7. Testing compilation. The accuracy of sbt's incremental compilation is tested using a custom test framework. With the new incremental compilation being more aggressive, more tests are needed. Basically, you define a project, changes to the project, and whether compilation should fail or succeed. This could be an opportunity to learn Scala in more depth. See sbt/src/sbt-test/ for example tests.
  8. Web support. If you use jetty-run and want to improve it, have at it. See the web subproject for the backend.
  9. Document how sbt components can used outside of sbt. Specifically, the incremental compilation and the task engine should be usable outside of sbt with some effort. Some requirements, such as recompilation working for any Scala version, make this involve wiring together some components. It would be very useful to show how this can be done and possibly make it simpler for the common cases.


  • If none of these opportunities look interesting, send an email to the mailing list and we'll try to find something. Again, these are suggestions. If only one part of a task seems interesting, that is probably not a problem.
  • Like with 0.6.x, once the first release (experimental snapshot, really) gets out, there will probably be biweekly releases with whatever work is ready.
  • See sbt's project definition for short descriptions of each subproject.