* Here we wire Aether into the Ivy dependency chain
* Add hooks into Aether to use Ivy's http library (so credentials are configured the same)
* Create the actual Resolver which extracts metadata information from Aether
* Deprecate old Ivy-Maven integrations
* Create hooks in existing Resolver facilities to expose a flag to enable the new behavior.
* Create notes documenting the feature.
* Create a new resolver type `MavenCache` which denotes how to read/write local maven cache metadata
correctly. We use this type for publishM2 and mavenLocal.
* Update failing -SNAPSHOT related tests to use new Aether resolver
* Create specification for expected behavior from the new resolvers.
Known to fix#1322, #321, #647, #1616
Adds project-level dependency exclusions:
excludeDependencies += "org.apache.logging.log4j"
excludeDependencies += "com.example" %% "foo"
In the first example, all artifacts from the organization
`"org.apache.logging.log4j"` are excluded from the managed dependency.
In the second example, artifacts with the organization `"com.example"`
and the name `"foo"` cross versioned to the current `scalaVersion` are
excluded.
- Fixes cached resolution being too verbose
- Adds new UpdateLogging named "Default"
- When global logLevel or logLevel in update is Debug, Default will
bump up to Full UpdateLogging.
* IncrementalCompiler IC object now holds the actual logic to start incremental compilation (rather than AggresiveCompiler or other)
* MixedAnalyzingCompiler ONLY does anlaysis of Java/Scala code
* Moved the AnalyzingJavaCompiler into the integration library so that necessary dependencies are visible.
* Force CompileSetup Equiv typeclass to use Equiv relations defined locally.
* Add toString methods on many of the incremental compiler datatypes.
* Remove remaining binary compatibility issues in Defaults.scala.
* Removed as many binary incompatibilities as I could find.
* Deprecating old APIs
* Attempt to construct new nomenclature that fits the design of Incremental API.
* Add as much documentation as I was comfortable writing (from my understanding of things).
This breaks the loading/saving of the incremental compiler analysis out
into separate task, thereby providing the necessary hooks for byte code
enhancement tasks to enhance bytecode and update the analysis before the
analysis gets stored to disk.
* Create a new sbt.compiler.javac package
* Create new interfaces to control running `javac` and `javadoc` whether forked or local.
* Ensure new interfaces make use of `xsbti.Reporter`.
* Create new method on `xsbti.compiler.JavaCompiler` which takes a `xsbti.Reporter`
* Create a new mechanism to parse (more accurately) Warnings + Errors, to distinguish the two.
* Ensure older xsbti.Compiler implementations still succeed via catcing NoSuchMethodError.
* Feed new toolchain through sbt.actions.Compiler API via dirty hackery until we can break things in sbt 1.0
* Added a set of unit tests for parsing errors from Javac/Javadoc
* Added a new integration test for hidden compilerReporter key, including testing threading of javac reports.
Fixes#875, Fixes#1542, Related #1178 could be looked into/cleaned up.
When conflicts are found for a given module, a forced one
is selected before conflict manager kicks in.
The problem is that DependencyDescriptor seems to mark transitive
forced dependency as forced as well,
so the actual forced dependency are sometimes not prioritized.
To work around this, I’ve introduced a mixin called
SbtDefaultDependencyDescriptor, which carries around ModuleID to detect
direct dependencies.
* Attempt to set publication date to last modified time, if the stars align
* Issue warning about undefined resolution behavior otherwise
* Add scripted test which exercises the NPE issue in resolving -SNAPSHOTs.
* Commit scalariform style edit in Act.scala
* After parsing and transforming the pom, check for pub date.
* If we don't have a pub date, try to grab lastModified from the URL
* If we can't do anything, issue a warning about the problem artifact.
The optimization, and therefore the change in the behavior
of Relation, is now needed by the class Logic, and cannot
be reverted.
This patch (written by Josh) therefore changes the
implementation of setAll() so that _1s is no longer used.
Fixes#1568.
This is the fallout of attempting not to leak config-file classes. Since
we DO NOT have valid incremental compiler for config-classes, we've instituted
workaround to ensure that regular incremental compilation *AND* our own
sbt loader do not hose each other. A full solution will eventually be
to find a way for .sbt files to participate in regular compilation of a
project.
For now, we fix the tracking of generated.class files throughout an sbt
"loadProjects" call, and then clean any .class files that were not
generated for a full reload. This commit just fixes
a minor tracking issue.
#1525 removes unused *.class files created by the metabuid.
The implementation currently prints out a long list of *.class files
it’s about to remove. Unless something bad happens, this information is
not very useful to the user, so I suggest we don’t display it.
Scala instance is added to the Ivy graph via autoLibraryDependency.
For metabuilds, scala-library is scoped under “provided” configuration,
which does not seem to evict modules on “compiled” configuration.
This commit turns overrideScalaVersion flag to true for the metabuilds,
so override rules are added for the following modules:
- scala-library
- scala-compiler
- scala-reflect
Fixes#1524
* Track generated .class files from Eval
* While loading, join all classfiles throughout Load, lots of bookkeeping.
* When a given build URI is done loading, we can look at its
project/target/config-classes directory and clean out any extra items
that are lingering from previous build definitions.
* Add TODOs to handle the same thing in global directories. Right now,
given the shared nature of these projects, it's a bit too dangerous to
do so.
First of all, we revert changes to Eval made in
a9cdd96152. That was a work-around
for problem with broken positions set on some trees. The rest of
the commit describes a fix.
Scala compiler's Global has `currentRun` method which is supposed to
return an instance of Run currently in use. Sbt's Eval which wraps
Global would create an instance of Run but not register it in Global.
Similarly, Eval would create an instance of `CompilationUnit` but not
set it in Run.
This would result in some silent failures like assigning broken positions
to parsed trees even if parser *has* received an instance of compilation
unit. See https://issues.scala-lang.org/browse/SI-8794 for details.
We fix the issue by subclassing Global and making it possible to set
current Run instance externally. Then we use this capability to set a run
instance right before we call compiler phases. We also make sure that
current run has current compilation assigned to it.
Fixes#1181Fixes#1501Fixes#1523
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.
eugene yokota
Josh Suereth
xuwei-k
andrzej.jozwik@gmail.com
Jean-Rémi Desjardins
James Roper
j-keck
Peter Vlugter
Tomasz Bartczak
andrzej.jozwik@gmail.com
Jacek Laskowski
Antonio Cunei
Daniel Peebles
Havoc Pennington
Grzegorz Kossakowski
Lukasz Piepiora
Dan Sanduleac
cheeseng
Paul Phillips
Martynas Mickevicius
Bruno Bieth
Indrajit Raychaudhuri
David Barri