sbt/notes

DONE
 - fixed Jetty 7 and JRebel
 - fixed make-pom and missing <repositories> tag
 - fixed referencing xsbti classes from project definition and plugins
 - 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.

Goals/Guidelines for xsbt
=====
As usual:
 - Immutable interfaces
 - Typesafe
 - Robust, flexible API
 
TODO
 - 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)

- 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
- boot interface contains static final int version = N that main xsbt can use to check if it can be loaded by that version (a lower bound check)
- main xsbt has static final int version = N that boot can use to check if it can load that version (a lower bound check)