Contributing to sbt

Below is a running list of potential areas of contribution. This list
may become out of date quickly, so you may want to check on the
sbt-dev mailing list if you are interested in a specific topic.

There are plenty of possible visualization and analysis
opportunities.

’compile’ produces an Analysis of the source code containing

Source dependencies

Inter-project source dependencies

Binary dependencies (jars + class files)

data structure representing the
API of the
source code There is some code already for generating dot
files that isn’t hooked up, but graphing dependencies and
inheritance relationships is a general area of work.

Ivy produces more detailed XML reports on dependencies. These
come with an XSL stylesheet to view them, but this does not
scale to large numbers of dependencies. Working on this is
pretty straightforward: the XML files are created in ~/.ivy2
and the .xsl and .css are there as well, so you don’t even need
to work with sbt. Other approaches described in the email
thread

Tasks are a combination of static and dynamic graphs and it
would be useful to view the graph of a run

Settings are a static graph and there is code to generate the
dot files, but isn’t hooked up anywhere.

There is support for dependencies on external projects, like on
GitHub. To be more useful, this should support being able to update
the dependencies. It is also easy to extend this to other ways of
retrieving projects. Support for svn and hg was a recent
contribution, for example.

If you like parsers, sbt commands and input tasks are written using
custom parser combinators that provide tab completion and error
handling. Among other things, the efficiency could be improved.

The javap task hasn’t been reintegrated

Implement enhanced 0.11-style warn/debug/info/error/trace commands.
Currently, you set it like any other setting:

set logLevel := Level.Warn

or
: set logLevel in Test := Level.Warn

You could make commands that wrap this, like:

warn test:run

Also, trace is currently an integer, but should really be an abstract
data type.

​7. Each sbt version has more aggressive incremental compilation and
reproducing bugs can be difficult. It would be helpful to have a mode
that generates a diff between successive compilations and records the
options passed to scalac. This could be replayed or inspected to try to
find the cause.

Documentation

There’s a lot to do with this documentation. If you check it out
from git, there’s a directory called Dormant with some content that
needs going through.

the main page mentions external project references (e.g.
to a git repo) but doesn’t have anything to link to that explains
how to use those.

API docs are much needed.

Find useful answers or types/methods/values in the other docs, and
pull references to them up into /faq or /Name-Index so people can
find the docs. In general the /faq should feel a bit more like a
bunch of pointers into the regular docs, rather than an alternative
to the docs.