notes

- script tasks (in 'scripts' branch).  To use:
 1) add implementation of jsr223 to project/build/lib, declare in project/plugins, or add to sbt startup classpath
 2) Mix sbt.scripts.Scripts into your project definition
 3) Create project/scripts/name.ext
 4) Run as 'name'
 5) To work with dependencies, get the task from the scriptedTasks map by name.  Ex:
   lazy val myTask = task { ... } dependsOn scriptedTasks("myscript").

 - added experimental 'sbt-update version [output.jar]' command enabled by mixing in UpdateSbt trait.  It probably doesn't work on Windows, but confirmation either way would be helpful.
  Changes 'sbt.version' after verifying the version is valid by downloading that version of sbt.
  Updates the current launcher jar or the location specified in the second argument with either a downloaded sbt-launch-<version>.jar if available or a copy of the current launcher jar that uses <version> by default when starting new projects.

TODO:
 - tasks as promises
 - aggressive recompilation
 - API API.  Read, write, search API.
 - source build system

 - launcher interface versioning
 - allow comments in datatype definition file
 - tests for API extractor
 - have background triggered commands (~sync)

Task engine
- method tasks will be normal tasks that pull the command line from a CommandLine task
- per task configuration, including logging (e.g. 'task compile log debug')
- unnamed tasks log to parent task
- better control over parallel logging.  Approach undecided. Some possibilities:
  + optionally one task always logging
  + log each task to a file
  + interactive control over logging (might require tasks that use console to be explicit in their dependence on the console)

- should be able to connect one preprocessor to another

- Interfaces subproject that depends on no other project and defines interfaces in package xsbti.  They are written in Java and cannot refer to Scala classes (compileOrder = JavaThenScala).  These interfaces can be used to pass objects across ClassLoader boundaries.
- launcher/main interface is not static (no system properties should be used past the static entry point)
- simple, well-defined ClassLoaders
- use Exceptions instead of Option/Either
- every component gets its own subproject
- can use any version of compiler/Scala that is source compatible with the compiler-interface component
- build xsbt using normal cross-build conventions
- compiler: raw interface (no dependency analysis, but still in same jvm) or with dependency analysis
- compiler: can specify scala-library.jar and scala-compiler.jar + version instead of retrieving the ClassLoader
- compiler: new phase that extracts API defined in sources (classes, their members, and all type information)
- minimal dependence on main xsbt logger from subcomponents: use thin interface for subcomponents

Dependency Management
- resolvers are completely defined in project definition (use Resolver.withDefaultResolvers)
- configurations completely defined within project (use ModuleConfiguration.configurations)

Launcher
- see launch.specification