Set sbt.task.timings=true to print timings for tasks.
This sample progress handler shows how to get names for tasks and
deal with flatMapped tasks. There are still some tasks that make
it through as anonymous, which needs to be investigated.
A setting to provide a custom handler should come in a subsequent commit.
* Consolidate project ID validation and normalization into Project methods
* Provide an earlier and more detailed error message when the directory
name can't be used for the project ID
The Help for these commands now needs to be cleaned up, since they were not written with
this feature in mind. In particular,
* consider adding syntax summaries in the short help strings
* alternatively, add the syntax summary data elsewhere for use specifically by this feature
* display a better message when there is no short help string, such as
"See 'help <command>' for usage." or just displaying the lower level error message, such as
"Expected whitespace"
-Changed usages and implementations of interfaces in org.scalatools.testing._ to use/implement interfaces/classes in sbt.testing._ instead.
-Added sbt.testing to interfaceFilter in TestFramework.createTestLoader method to enable loading of classes in sbt.testing package.
-Added FrameworkWrapper.java to wrap old framework implementations.
-Added code in ForkMain.java to serialize Selectors.
For the global plugins project, the default ID is "global-plugins".
For a normal project, the default ID is the name of the build directory.
The ID of a build definition for one of the above appends -build.
This fixes an infinite loop when defining a Project in a .sbt file
with the build base directory as the project base directory.
This allows the standard behavior for interpreting settings from
.sbt files for both Projects defined in .sbt files as well as in
.scala files. That is, settings in .sbt files in "." go in all
projects with "." as their base directory.
Ref #554.
* No longer override the Scala version to force it to be scalaVersion. Custom configurations might use an independent version.
* Only substitute the jars from scalaHome when the major.minor versions line up for the substituted artifact
* Allow the Scala version to use for dependency resolution to be specified when using ++ to change Scala home: ++ version=/path/to/scala/home
Specifically, when the Scala version for sbt is the same as that for the project being built,
the jars in UpdateReport should be the same as those in ScalaProvider. This is because the
loader will come from the ScalaProvider, which uses jars in the boot directory instead of the
cache. The first part of the fix for #661 checks that loaded classes come from the classpath
and so they need to line up.
It is now used for consoleProject, run, and test. This loader verifies
that all classes loaded through it came from a particular classpath or
from the "root" loader. Root loader here is the launcher loader so that
those classes with native bindings come from that shared loader.
Introduce a way to configure incremental compiler itself instead
of underlying Java/Scala compiler.
Specific list of changes in this commit:
* Add a method to `xsbti.compile.Setup` that returns incremental
compiler options as a `java.util.Map<String, String>`. We considered
statis interface instead of a `Map` but based on mailing
list feedback we decided that it's not the best way to go because
static interface is hard to evolve it by adding new options.
* Since passing `java.util.Map<String, String>` not very convenient
we convert it immediately to `sbt.inc.IncOptions`
* Add options argument to various methods/classes that implement
incremental compilation so in the end options reach
`sbt.inc.IncOptions` object
* Add `incOptions` task that allows users to configure incremental
compiler options in their build files. Default implementation of
that tasks returns just `IncOptions.DEFAULT`
* Both system property `xsbt.inc.debug` and `IncOptions.relationsDebug`
trigger debugging of relations now. In the near future, we should
deprecate use of `xsbt.inc.debug`.
Some methods take a lot of arguments and I'm about to add one more
which will make them too long for easy reading.
This change is changes code formatting only. That's done on purpose
to make it easier to review other changes.
Needed an explicit type in PMap to workaround an error.
Need to drop tuple assignment of parser.parsed in input task macro as a workaround
for macro/resetAllAttrs/pattern matching/annotation issue in RC1.
Let's consider compile/inc/src/main/scala/sbt/CompileSetup.scala.
There are multiple Output types, and according to Eclipse importing
xsbti.compile.Output within the package sbt does not work because the
import is shadowed by sbt.Output.
However, compilation proceeds just fine within SBT. Reproducing the
example however gives the same warning, if the files are in the same
project. The problem here is probably that the shadowing Output
is declared in the same package but in another project, and that seems
to give different results in Eclipse and SBT, but relying on
that looks fragile.
Reading the spec is inconclusive since it doesn't match with Scalac's
behavior — see
https://groups.google.com/d/topic/scala-internals/-Rquc2HBYLk/discussion .
ForkTests has the same behavior as CompileSetup.
The Project.setSbtFiles and addSbtFiles methods combined with the current sbt version
available from ComponentMangaer.version (suggestions for a better location are welcome),
should make it straightforward to load different .sbt files based on the sbt version.
Fixes#467.
Set autoAPIMappings := true to enable.
Then, set apiURL to the base URL of the API documentation for a project.
This will get stored in an extra attribute in the ivy.xml or as a property
a pom.xml.
When using managed dependencies that have set their apiURL, the -doc-external-doc
setting for scaladoc will be automatically configured. Note that this option
will only be available in Scala 2.10.1 and so enabling autoAPIMappings for
earlier versions will result in an error from scaladoc.
For unmanaged dependencies or dependencies without an automatic apiURL, add the
(File,URL) mapping to apiMappings. The File is the classpath entry and the URL
is the location of the API documentation.
- override location of resolved Scala jars when scalaInstance is unmanaged
- document current behavior: scalaHome, update, scalaInstance, autoScalaLibrary, managedScalaInstance
* If SBT launcher supports app repositories these are added by default.
* IF SBT launcher does not support app repositories, previous defaults are used.
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.
* Puppies may rest easy from the removal of Option.get calls.
* better names for config values
* Added a helper method to avoid any possible code duplication, besides repeated def, val, match and for keywords.
Looking for ways to remove this duplciation ASAP.
* Moved from pattern match to ._1, my most hated member.
Problems:
1. Without a message, users don't find 'last'
2. Showing a message for every error clutters output.
This tries to address these issues by:
1. Only showing the message when other feedback has not been provided and
'last' would not usually be helpful. This will require ongoing tweaking.
For now, all commands except 'compile' display the message. 'update' could
omit the message as well, but perhaps knowing about 'last' might be
useful there.
2. Including the exact command to show the output:
last test:compile
and not just
last <task>
3. Highlighting the command in blue for visibility as an experiment.
Review by @ijuma and @retronym, please.
Changed the order of parameters in getScala method.
Changed the key name to scalaOrganization (scala-organization).
Augmented description of the key.
Minor fixes.
Adding scalaOrg key that specifies organization (artifactId) of scala used in the project. The change does not affect version checks for dependecies and LauncherConfiguration.
Modified scalaProvider cache in Launcher to use (scalaOrg, version) as a key.
Downloaded jars are stored in the folder scala-.../lig-<scalaOrg> if scalaOrg is not default.
scala-org is an advanced setting so it can not be used in build.sbt.
Currently, only immediate parents classes are picked up for java classes.
This could be problematic, for example, in detecting Fingerprint for test frameworks.
So far, Scala types are not affected –– all the ancestors are available for them.
Warn when publish resolver and dependency resolvers have same name but different access mechanism.
Multiple resolvers having same name as well as same access mechanism (i.e., equality matching) isn't
usually a problem. A common scenario for this would be Maven based resolvers with exact (http based)
same access mechanism. Also see #367, #363
Simply, add `DefaultOptions.addResolvers` in project config
or `DefaultOptions.addPluginResolvers` in plugin config to have known
resolvers added by default (snapshot mode sensitive)
- deprecate scala-tools resolvers
- rename `typesafeResolver` to `typesafeReleases` for consistency
- add reference for other wel known resolvers, viz., oss.sonatype.org and scalasbt.artifactoryonline.com
- rearrange locations for helper methods
Mark Harrah
Eugene Yokota
cheeseng
Alex Dupre
Grzegorz Kossakowski
Paolo G. Giarrusso
Josh Suereth
Eugene Vigdorchik
Eric Bowman
Kevin Scaldeferri
James Roper
Indrajit Raychaudhuri
xuwei-k
Johannes Rudolph
Eugene Vigdorchik
Gerolf Seitz
Vojin Jovanovic
Michael Allman
Vojin Jovanovic
James Earl Douglas