1. Hyphenated labels are still accepted when parsing scoped keys (so 'sbt test-only' still works)
There is currently no timeline for removing this support for hyphenated keys.
2. Only camelCase is shown for tab completion.
3. AttributeKey.rawLabel provides the unnormalized label.
This should only be used to implement support for accepting hyphenated keys as input for compatibility.
4. AttributeKey.normLabel provides the normalized label (hyphenated converted to camelCase)
Similar to task macros, the parsed value is accessed by calling `parsed`
on a Parser[T], Initialize[Parser[T]], or Initialize[State => Parser[T]].
Values of tasks and settings may be accessed as usual via `value`.
1. Scala jars won't be copied to the boot directory, except for those needed to run sbt.
2. Scala SNAPSHOTs behave like normal SNAPSHOTs. In particular, running `update` will properly re-resolve the dynamic revision.
3. Scala jars are resolved using the same repositories and configuration as other dependencies.
4. Classloaders (currently, Scala classloaders) are cached by the timestamps of entries instead of Scala class loaders being cached by version.
TODO: Support external dependency configuration
In order to correctly pattern match Tree subclasses in reflection/macros,
scalac needs the corresponding implicit for *Tag available because the types
are only abstract types.
That is, implement Initialize[Task[T]].flatten correctly.
This requires preserving the transformations applied in a scope so that
they can be applied to an Initialize value after static settings have been
evaluated.
* use normal TypeTree constructor
* remove unnecessary 'with Singleton' in macro utility
* integrate changes suggested by @xeno-by
* add refVar back and call asTypeConstructor instead of asType to refer to a type variable
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
* split several source files
* move base settings sources (Scope, Structure, ...) into main/settings/
* breaks cycles. In particular, setting system moved from Project to Def
* must start with val, lazy val, or def (no modifiers currently)
* visible only within the same .sbt file
* multiple definitions allowed without being separated by blank lines
* no blank lines allowed within a definition
Project.autoSettings accepts a sequence of AddSettings, instances of which
are constructed from methods in AddSettings. The configurable settings
are per-user settings (from ~/.sbt, for example), settings from .sbt files,
and plugin settings (project-level only). The order in which these instances
are provided to autoSettings determines the order in which they are appended
to the settings explicitly provided in Project.settings.
For .sbt files, defaultSbtFiles adds the settings from all .sbt files in the
project's base directory as usual. AddSettings.sbtFiles accepts a sequence
of Files that will be loaded according to the standard .sbt format. Relative
Files are resolved against the project's base directory.
Plugin settings may be included on a per-Plugin basis by using the plugins
method and passing a Plugin => Boolean. The settings controlled here are
only the automatic per-project settings. Per-build and global settings will
always be included.
alias only parses the right hand side for tab completion help.
The assignment should happen whether or not the parse is successful because the
context may change by the time the alias is actually evaluated.
In particular, the 'set' command uses the loaded project for tab completion in 0.12.1.
When a .sbtrc file is processed, the project has not been loaded yet, so aliases
involving set fail. Wrapping the rhs in failOnException addresses this.
These special types need to be recognized in both the POM parser and added to the classpath.
The previous code was not DRY, and eclipse-plugin was in one but not the other. This ensures
new types can be added in the future without risking this type of oversight.
The module definition (ModuleID) got copied as to be the dependency definition,
but as a dependency definition, it should not include explicit artifacts.
Mark Harrah
Eugene Vigdorchik
Eric Bowman
Kevin Scaldeferri
James Roper