This allows plugins to define a Plugins instance that captures both the
plugin and its required dependencies.
Also fixed up some scaladocs that were wrong.
* packageArtifacts is not cleared by defautlSettings
* Added a test for this behavior (this one test should ensure the ordering for most settings is correct.)
Fixes#1176
We cannot break existing users, but we can deprecate the improper usage.
This is part #2 of the workaround for #1156. This ensures that
users will stop using the legacy methods after 0.13.2 is out.
AddSettings should only expose coarse-grained features of AutoPlugins
or else the Logic we use to ensure safe addition completely breaks
down. Leaving it in the code as an escape hatch if we get desparate,
but we need an alternative for controlling ordering later.
* GlobalPlugin has defaults for controlling parallelism on tasks, basic command stuff.
* IvyModule has the configuration for resolving/publishing modules to ivy, assuming
each project is a single module.
* JvmModule has the configuration for compiling/running/testing/packaging Java/Scala
projects.
* Add new AutoPlugins type to AddSettings.
* Ensure any Plugins filter doesn't just automatically always add
autoplugins every time.
* Load.scala can now adjust AutoPlugins ordering
Note: Adjusting autoplugin ordering is dangerous BUT doing a glob
of "put autoplugin settings here" is generally ok.
* remove the notion of Natures from Autoplugins.
* Update tests to use AutoPlugins with no selection for inclusion.
* Rename exisitng Natures code to Plugins/PluginsDebug.
Fixes#1155.
It seems that somehow during the 0.13.{1 -> 2 } transition, we
stopped pointing at the correct key for TaskKeys (either that or
task streams are now all associated with the `streams` key). I
think this may have been inadvertently caused from several
refactorings to enable greater control over the execution of tasks.
This points the `last*` methods at the correct key for tasks,
fixing both `last <key>` and `export <key>` commands.
* 'plugins' displays the list of plugins available for each build along with the project IDs each is enabled on
* 'plugin <name>' displays information about a specific plugin in the context of the current project
- if the plugin is activated on the current project and if so, information about the keys/configurations it provides
- how the plugin could be activated if possible
* tries to detect when it is run on an aggregating project and adjusts accordingly
- indicates if an aggregated project has the plugin activated
- indicates to change to the specific project to get the right context
This is a rough implementation and needs lots of polishing and deduplicating.
The help for the commands needs to be added/expanded.
* Can provide suggestions for how to define a plugin given a context (a loaded Project in practice).
* When a user requests an undefined key at the command line, can indicate whether any (deactivated) plugins provide the key.
TODO:
* Hook up to the key parser
* Implement 'help <plugin>'
* Determine how to best provide the context (the current project is often an aggregating root, which is not typically a useful context)
- remove AutoPlugin.provides
* name comes from module name
* AutoPlugin is Nature-like via Basic
- Project.addNatures only accepts varags of Nature values
* enforces that a user cannot explicitly enable an AutoPlugin
* drops need for && and - combinators
- Project.excludeNatures accepts varags of AutoPlugin values
* enforces that only AutoPlugins can be excluded
* drops need for && and - combinators
* Alter the TaskProgress listener key to be `State => TaskProgress` so it
can be instantiated from the current server/sbt state.
* Expose the xsbti.Reporter interface for compilation through to sbt builds.
This requires a Format[T] to be implicitly available at the call site and requires the task
to be referenced statically (not in a settingDyn call). References to previous task values
in the form of a ScopedKey[Task[T]] + Format[T] are collected at setting load time in the
'references' setting. These are used to know which tasks should be persisted (the ScopedKey)
and how to persist them (the Format).
When checking/delegating previous references, rules are slightly different.
A normal reference from a task t in scope s cannot refer to t in s unless
there is an earlier definition of t in s. However, a previous reference
does not have this restriction. This commit modifies validateReferenced
to allow this.
TODO: user documentation
TODO: stable selection of the Format when there are multiple .previous calls on the same task
TODO: make it usable in InputTasks, specifically Parsers
The fix was made possible by the very helpful information provided by @retronym.
This commit does two key things:
1. changes the owner when splicing original trees into new trees
2. ensures the synthetic trees that get spliced into original trees do not need typechecking
Given this original source (from Defaults.scala):
...
lazy val sourceConfigPaths = Seq(
...
unmanagedSourceDirectories := Seq(scalaSource.value, javaSource.value),
...
)
...
After expansion of .value, this looks something like:
unmanagedSourceDirectories := Seq(
InputWrapper.wrapInit[File](scalaSource),
InputWrapper.wrapInit[File](javaSource)
)
where wrapInit is something like:
def wrapInit[T](a: Any): T
After expansion of := we have (approximately):
unmanagedSourceDirectories <<=
Instance.app( (scalaSource, javaSource) ) {
$p1: (File, File) =>
val $q4: File = $p1._1
val $q3: File = $p1._2
Seq($q3, $q4)
}
So,
a) `scalaSource` and `javaSource` are user trees that are spliced into a tuple constructor after being temporarily held in `InputWrapper.wrapInit`
b) the constructed tuple `(scalaSource, javaSource)` is passed as an argument to another method call (without going through a val or anything) and shouldn't need owner changing
c) the synthetic vals $q3 and $q4 need their owner properly set to the anonymous function
d) the references (Idents) $q3 and $q4 are spliced into the user tree `Seq(..., ...)` and their symbols need to be the Symbol for the referenced vals
e) generally, treeCopy needs to be used when substituting Trees in order to preserve attributes, like Types and Positions
changeOwner is called on the body `Seq($q3, $q4)` with the original owner sourceConfigPaths to be changed to the new anonymous function.
In this example, no owners are actually changed, but when the body contains vals or anonymous functions, they will.
An example of the compiler crash seen when the symbol of the references is not that of the vals:
symbol value $q3 does not exist in sbt.Defaults.sourceConfigPaths$lzycompute
at scala.reflect.internal.SymbolTable.abort(SymbolTable.scala:49)
at scala.tools.nsc.Global.abort(Global.scala:254)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIdent$1(GenICode.scala:1038)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:1044)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genLoadArguments$1.apply(GenICode.scala:1246)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genLoadArguments$1.apply(GenICode.scala:1244)
...
Other problems with the synthetic tree when it is spliced under the original tree often result in type mismatches or some other compiler error that doesn't result in a crash.
If the owner is not changed correctly on the original tree that gets spliced under a synthetic tree, one way it can crash the compiler is:
java.lang.IllegalArgumentException: Could not find proxy for val $q23: java.io.File in List(value $q23, method apply, anonymous class $anonfun$globalCore$5, value globalCore, object Defaults, package sbt, package <root>) (currentOwner= value dir )
...
while compiling: /home/mark/code/sbt/main/src/main/scala/sbt/Defaults.scala
during phase: global=lambdalift, atPhase=constructors
...
last tree to typer: term $outer
symbol: value $outer (flags: <synthetic> <paramaccessor> <triedcooking> private[this])
symbol definition: private[this] val $outer: sbt.BuildCommon
tpe: <notype>
symbol owners: value $outer -> anonymous class $anonfun$87 -> value x$298 -> method derive -> class BuildCommon$class -> package sbt
context owners: value dir -> value globalCore -> object Defaults -> package sbt
...
The problem here is the difference between context owners and the proxy search chain.
This feature is not activated by default. To enable it set `testForkedParallel` to `true`.
The test-agent then executes the tests in a thread pool.
For now it has a fixed size set to the number of available processors.
The concurrent restrictions configuration should be used.
The completions command is meant for dump terminals that cannot use
the default tab completion. It has been built for use by the emacs
sbt-mode (see https://github.com/hvesalai/sbt-mode), but is equally
useful for other code editors that can integrate with sbt.
This is a temporary workaround: it assumes nothing else uses these streams later.
This condition is ok for 'export' and test streams, since these are unlikely to
reuse these streams. However, the proper fix is for the TaskStreams methods
to be smarter- they could open in append mode if the stream was closed. The
streams associated with a task could be optimistically closed after it finishes executing.
(Any task can write to another task's streams, which is why it is an optimization only.)
Specify an Ivy resolver with ", descriptorOptional" to make Ivy
descriptor files optional for that repository or with
", skipConsistencyCheck" to disable Ivy consistency checks for
that repository.
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
-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`.
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.
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
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.
Eugene Yokota
James Roper
Josh Suereth
Mark Harrah
Dan Sanduleac
Jacek Laskowski
xuwei-k
Bruno Bieth
Heikki Vesalainen
Havoc Pennington
William Benton
Johannes Rudolph
cheeseng
Alex Dupre
Grzegorz Kossakowski