* Expose the values PAST the Eval/sbt.compiler package.
* Find projects using the name API rather than finding htem and dropping all values immediately.
* Adds a test to make sure the .sbt values are discovered and set-able
* Expose .sbt values in Set command and inside BuildUnit methods.
* Ensure `consoleProject` can see build.sbt values.
* Add notes for where we can look in the build if we want to expose .sbt values between files.
* Change detection of "default project" to accurately see
if someone has changed the organization.
* Add a flag to notify downstream consumers that a project
was autogenerated and not user specified.
Fixes#1315
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
This does the following:
* Fragments loading into two stages: Discovery + Resolution
* Discovery just looks for .sbt files and Projects, while
loading/compiling them.
* Resolution is responsible for taking discovered projects and
loaded sbt files and globbing everything together. This includes
feeding the project through various manipulations, applying
AutoPlugin settings/configurations and ordering all the settings.
* Add a bunch of docs
* Add direct DSL `enablePlugins` and test
* Add direct DSL `disablePlugins` and test.
* Create new DSLEntry type for settings so we can categorize what we parse
* Use DSLEntry to help solve the Setting[_] vs. Seq[Setting[_]] implicit fun.
* Hack away any non-Setting[_] DSLEntry for now.
* Add test in build.sbt to make sure the new DSL works.
This migrates JunitXmlReportPlugin to work the way we desire
new sbt features/plugins to work:
* Enabling the feature is having the plugin available.
* Disabling the feature is disabling the plugin
* All code/settings for the feature are isolated to the plugin.
* Add task to determine file-name of analysis cache
* If crossPaths := true, then add scala binary version to the analysis cache name.
This makes it possible to leverage incremental compilation with the `+` command.
Fixes#1267
Taken from https://github.com/chenkelmann/junit_xml_listener and slightly improved.
Activating is now just a matter of setting `testReportJUnitXml` to true.
This not only brings a very handy feature (hudson/jenkins support that syntax),
but gives more options for testing the SBT test infrastructure.
For instance checking that the test output is well segregated during a parallel
test run is just a matter of checking the report output.
Conflicts:
main/src/main/scala/sbt/Keys.scala
Fixes#1223.
* Add a new key to disable forcing the garbage collector to run
after each task-executioin
* Add a new flag to disable forcing the garbage collector to run
after each task-exeuction
* Add a hook into EvalauteTask to run System.gc/System.runFinalization
after each task execution
Review by @eed3si9n
Within buildPluginDefinition(), the call to setProject() can
(and usually will) return a modified structure together with
the new state.
The subsequent call to evalPluginDef() should use the updated
structure, rather the old stucture that was present before
the setProject() ("pluginDef"); if that is not the case,
the code called by evalPluginDef() will find an inconsistent
structure/state combination, and behave in bizarre ways as
a result.
More in general, it is a bit dangerous to pass to routines
in parallel the two separate state and structure, as the
two may easily inadvertently fall out of alignment, as in this
case.
This patch should be applied to both the 0.13 branch as well
as to a future 0.12.5 release (the corresponding file there
is ./main/Load.scala).
Add logging of various operations the transactional class file manager is
doing. You can pass logger to be used by the transactional class file
manager by using overloaded definition of `ClassfileManager.transactional`
method. The old overload has been deprecated.
The factory methods for class file manager in IncOptions companion object
has been deprecated in favor of using ClassfileManager companion object
directly. The code in Defaults.scala has been updated to use non-deprecated
methods. The logging is turned off by default.
The canonical way of enabling transactional class file manager in sbt
project is:
```
incOptions := incOptions.value.withNewClassfileManager(
sbt.inc.ClassfileManager.transactional(
crossTarget.value / "classes.bak",
(streams in (compile, Compile)).value.log
)
)
```
It's a bit verbose which shows that the api for this is not the best.
However, I don't expect sbt users to need this code very often.
This patch should help debug the problem described in #1184
The deprecated method should forward to the other overloaded alternative
but it recursed instead.
This kind of mistake would be easily caught by linter warning about
unused `newConfig` local variable. I hope we'll get there some day.
Fixes#1251
`DefaultOptions.addResolvers` and `DefaultOptions.addPluginResolvers`
should not reset the existing value while adding the new ones. The
names are prefixed with _add_ afterall.
1) When `test` is run and there are no tests available, omit logging output.
Especially useful for aggregate modules. `test-only` et al unaffected. (#1185)
2) Added a new setting `testResultLogger` to allow customisation of logging of test results.
* Expose new EvaluateTaskConfig throughout all the APIs
* Create a key for cancellation configuration
* Add default values for cancellation in GlobalPlugin
* Create a test to ensure that cancellation can cancel tasks.
* Deprecate all the existing mechanisms of evaluating tasks which
use the EvaluateConfig API.
* Create a new EvaluateTaskConfig which gives us a bit more freedom
over changign config options to EvaluateTask in the future.
* Create adapted from old EvaluateTask to new EvaluateTask
* Add hooks into signals class to register/remote a signal listener
directly, rather than in an "arm" block.
* Create TaskEvaluationCancelHandler to control the strategy of
who/whom can cancel (sbt-server vs. sbt-terminal).
* Create a null-object for the "can't cancel" scenario so the
code path is exactly the same.
This commit does not wire settings into the build yet, nor does it
fix the config extractio methods.
* AutoImport trait is subsumed by def autoImport method under
AutoPlugin class.
* When def autoImport is overridden by a lazy val or a val, *.sbt
automatically imports autoImport._.
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.
In 2.11, the implicit version is named `$conforms` so as to avoid
accidental shadowing by user code, which renders methods using
views and subtype bounds inexplicable unusable.
But, SBT intentionally needs to hide it to make the implicits
in this file line up.
This commit opts-in the the required identifiers from Predef,
rather than opting out of conforms. This makes the same code
source compatible with 2.10 and 2.11.
* '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)
This commit makes the code source compatible across Scala 2.10.3
and https://github.com/scala/scala/pull/3452, which is proposed
for inclusion in Scala 2.11.0-RC1.
We only strictly need the incremental compiler to build on Scala
2.11, as that is integrated into the IDE. But we gain valuable
insight into compiler regressions by building *all* of SBT with
2.11.
We only got there recently (the 0.13 branch of SBT now fully cross
compiles with 2.10.3 and 2.11.0-SNAPSHOT), and this aims to keep
things that way.
Once 2.10 support is dropped, SBT macros will be able to exploit
the new reflection APIs in 2.11 to avoid the need for casting
to compiler internals, which aren't governed by binary compatibility.
This has been prototyped by @xeno-by: https://github.com/sbt/sbt/pull/1121
We now have `global.Range`, so our wildcard import of `global._`
shadows `scala.Range`.
This commit fully qualifies that type so as to be compatible with
Scala 2.10 and 2.11.
- 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
Untyped trees underneath typed trees makes Jack and sad boy.
And they make superaccessors a sad phase.
The recent refactoring to retain original types in the trees
representing the argument to the task macro meant that the `value`
macro also was changed to try to avoid this untyped-under-typed
problem. However, it didn't go deep enough, and left the child
trees of the placeholder tree `InputWrapper.wrap[T](key)` untyped.
This commit uses `c.typeCheck` to locally typeheck that tree fully
instead.
Fixes#1031
* 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
This avoids an additional cause of recursion via the semicolon/multiple command, which fixes#933.
It also provides error messages on the expanded command. This fixes#598.
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.)
If an exception is thrown when accepting a connection from a forked test
agent, currently I'm seeing that all that happens is SBT hangs with no
output. Thread dumps show that the main process is waiting for the
agent to return, while the agent is waiting for the server to send it
something.
This change logs the exception, so that at least the error can be
googled. It also cleans up the server socket.
This protects against deadlocks between the writing and reading end,
since the ObjectOutputStream constructor writes a header, but does not
flush, and the ObjectInputStream constructor reads the header, and
blocks until it's read.
The serialized structures there aren't part of an Analysis,
so they aren't interned.
TODO: Refactor InternedAnalysisFormats so that this is more
straightforward and less error-prone. This commit is
a first-pass fix of the broken test.
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
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
So far we had ability to configure compile task specific settings on
`Compile` Configuration scope only. We can now add `compile` task scope
as well.
Usecase: one can now specify:
```
// applies for all tasks on Compile axis
scalacOptions in Compile += "-deprecation"
// applies for compile tasks on Compile axis
scalacOptions in (Compile, compile) += "-Xcheckinit" // effectively, "-deprecation -Xcheckinit"
```
The old convention of keeping credentials in ~/.ivy2 isn't recommended anymore,
they can instead go in (customizable) global base location.
The global base defaults to `~/.sbt`, hence credentials go in `~/.sbt/.credentials`
(c.f. `Keys.globalBaseDirectory` and system property `sbt.global.base`)
Sonatype OSS repo (where many libraries are expected to migrate) requires
populating SCM info in additional to what is already provisioned for
populating in SBT.
We now support populating the basic SCM info as thus:
```
// Usual <scm><url/><connection/></scm>
scmInfo := Some(ScmInfo(url("https://github.com/foo/project"), "scmhttps://github.com/foo/project.git"))
// Also add <developerConnection/>
scmInfo := Some(ScmInfo(url("https://github.com/foo/project"), "scmhttps://github.com/foo/project.git", Some("dev_connection")))
```
For anything more esoteric than the basic info, there is always `pomPostProcess` :)
Old implementation of the local resolver did not copy directory if it
was writable. This optimization can lead to some potential problems if
the directory is writable, but its subdirectories aren't.
New implementation of the local resolver does not have this
optimization and it always copies the directory into staging area.
All subversion URIs have to be prefixed with 'svn:' to separate them
from URIs for other resolvers. For example, 'svn:https://server/repo'
can now be used.
All mercurial URIs have to be prefixed with 'hg:' to separate them
from URIs for other resolvers. For example,
'hg:https://server/user/repo' can now be used.
Non-standard git URIs are ones that do not start with 'git:' nor end
with '.git'. An example of non-standard git URI is
'ssh://server/home/user/repo'.
The mechanism for specifying a non-standard git URI is done by
prefixing the whole URI with 'git:' to signify that it should be
handled with the git resolver. For example, non-standard git URIs like
'git:ssh://server/user/repo' and 'git:https://server/user/repo' can
now be used.
Instead of cloning from a remote git repository for each branch,
revision or tag separately, the git resolver locally clones only once
the remote git repository and then creates further local clones from
this local copy of the remote repository.
First, optimization, of course, is execution speed, because cloning
local repository is much faster than remote repository. Furthermore,
because git uses hard-linking when a clone of local repository is
created, the second optimization is in space consumption.
For example, if we have one project that uses
https://github.com/harrah/xsbt.git#v0.11.1 and second project that
uses https://github.com/harrah/xsbt.git#v0.11.2, in previous git
resolver implementation it would require two separate clones of the
remote git repository at https://github.com/harrah/xsbt.git. But, the
new git resolver requires only one clone of the remote git repository
and two local clones which take no space because of hard-linking.
System propery sbt.global.plugins configures global plugins directory
default: $sbt.global.base/plugins
System property sbt.global.staging configures global staging directory
default: $sbt.global.base/staging
System property sbt.global.settings configures directory containing global .sbt files
default: $sbt.global.base
This is a slightly cleaned up version of sbt-inspectr. When "inspect
tree <key>" is called, SettingGraph case class is created recursively
along the dependencies, calling the similar code as "inspect" command's
Project.details. Graph object then renders it as an ascii tree.
`docSetting` has been updated to do both Scaladoc and Javadoc. In
Scala/Java hybrid projects, the output docs are rebased to `scala`
or `java` sub-directory accordingly. But for pure scala or pure java
projects the subdirectories aren't added to becompliant with user
expectation as much as possible. We do hybrid mode iff both *.scala
and *.java files exist; other doc resources (package.html, *.jpg etc.)
don't influence the decision.
Josh Suereth
Peter Vlugter
Lukasz Piepiora
eugene yokota
Jacek Laskowski
Dan Sanduleac
cheeseng
Paul Phillips
Martynas Mickevicius
Bruno Bieth
Antonio Cunei
Grzegorz Kossakowski
Indrajit Raychaudhuri
David Barri
Sergey Andreev
James Roper
Jason Zaugg
Mark Harrah
Simeon H.K. Fitch
xuwei-k
Heikki Vesalainen
Benjy
Havoc Pennington
William Benton
Johannes Rudolph
Alex Dupre
Paolo G. Giarrusso
Eugene Vigdorchik
Eric Bowman
Kevin Scaldeferri
Johannes Rudolph
Eugene Vigdorchik
Gerolf Seitz
Vojin Jovanovic
Michael Allman
Vojin Jovanovic
James Earl Douglas
Sanjin Sehic
Holden Karau
杨博
