Fixes#1455
* Add a mechanism to detect if a plugin clause includes/excludes
a particular plugin.
* Add a filter for our "enabling" clauses so that user-excluded
root plugins do not show up.
* Add a test to ensure this succeed.
When the compiler reports back the error to CompilationUnit created by Eval#mkUnit, it sometimes returns OffsetPosition whose `source` is set to `NoSourceFile`.
This causes ArrayIndexOutOfBoundsException. The current workaround is to pattern match on the passed in pos and create a new one when the incoming source looks suspicious.
I have not figured out whether this is caused by our macro code or compiler.
There are various build.sbt errors that would cause this behavior:
```scala
libraryDependencies ++= Seq(
depA
depB // missing comma
)
lazy val bob = scala.Console println
test ++
run+
```
Scope.parseScopedKey now supports full range of legal keys
described in the documentation including {.} and other
notation for ProjectRef, BuildRef, and ThisBuild.
UnresolvedWarning is moved back to IvyActions.scala where it belongs.
The mapping between ModuleID and SourcePosition is passed in as UnresolvedWarningConfiguration.
This is calculated once in Defaults using State and is cached to filesystem.
Unresolved dependency warning is moved to UnresolvedDependencyWarning class including
the fail path that was added in #1467.
To display the source position, I need to access the State, so I had to move the
error processing out of IvyActions and add UnresolvedDependencyWarning, which is
aware of State.
* Ensure the ++ command stores its changes on the sbt session.
* Make sure `session clear-all` will clear out ++ changes
* Validate that `set` command doesn't undo `++` changes
Note: There is some autogenerated Setting[_] delegate optimisation
work that could be done in the future.
* Migrate weak reference into logger class so we can test clearing it.
* Ensure new state.log is propoagted into settings on `set` command.
* Fix set test so that it ensures the sLog is relatively stable when
reloading on set command.
This implements all stories from https://github.com/sbt/sbt/wiki/User-Stories%3A-Conflict-Warning.
When scalaVersion is no longer effective an eviction warning will display.
Scala version was updated by one of library dependencies:
* org.scala-lang:scala-library:2.10.2 -> 2.10.3
When there're suspected incompatibility in directly depended Java libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* commons-io:commons-io:1.4 -> 2.4
When there's suspected incompatiblity in directly depended Scala libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4
This also adds 'evicted' task, which displays more detailed eviction warnings.
Currently sbt's update task generates UpdateReport from
Ivy's resolution report.
For each configuration there's ConfigurationReport, which contains
just enough information on the resolved module/revision/artifact.
Speaking of module, in Ivy module means organization and name,
and organization, name, and version is called module revision.
In sbt, module revision is called Module.
This is relevant because to talk about evictions, we need
a terminology for organization and name combo.
In any case ConfigurationReport is expanded to have `details`
field, which contains Seq[ModuleDetailReport], which represents
organization and name combo plus all the modules
just like Ivy's resolution report XML.
Furthermore, ModuleReport is expanded to include licenses,
eviction, callers, etc.
This adds a new setting key called updateOptions, which can enable
consolidated resolution for update task.
The consolidated resolution automatically generates an artificial
module descriptor based on the SHA-1 of all external dependencies.
This consolidates the Ivy resolution of identical Ivy dependency
graph across multiple subprojects.
This is how it's enabled:
updateOptions := updateOptions.value.withConsolidatedResolution(true)
* 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
Josh Suereth
Eugene Yokota
Jacek Laskowski
Peter Vlugter
Lukasz Piepiora
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