* 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
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.
Since sbt 0.13.0, we have dedicated API in Analysis that gives access to
information about all compilations performed since the last time clean
was ran.
By looking at at last compilation we can determine lastCompilationTime
value.
Fixes#1272
* Testing the infrastructure to use our own instance of ivy
* Allow us to push bug-fixes/performance directly into ivy
on our own pace, as we submit patches back to ivy master
The ff0fd6eec6 introduced some exclusions
that were necessary for getting sbt to resolve dependencies properly
against Scala 2.11.0-M7.
Scala 2.11.0-M8 fixed its dependency structure so we can get rid of those
exclusions now.
This entailed modifying ResolutionCache and the CustomPomParser
to reflect changes to the ResolutionCacheManager interface and
DefaultExtendsDescriptor class between Ivy 2.3.0-rc1 and
2.3.0-rc2. Specifically,
1. ResolutionCacheManager now includes two additional methods
that needed implementations in ResolutionCache:
getResolvedModuleDescriptor(mrid: ModuleRevisionId) and
saveResolvedModuleDescriptor(md: ModuleDescriptor). I adapted
the implementations for these (which are expressed primarily in
terms of other interface methods) from Ivy 2.3.0's
DefaultResolutionCacheManager.
2. Instead of taking a ModuleRevisionIdentifier and a resolved
ModuleRevisionIdentifier as its first two arguments, the
DefaultExtendsDescriptor constructor now takes a
ModuleDescriptor. This was a trivial change.
Note that ResolutionCache.getResolvedModuleDescriptor does not
appear to be used by Ivy as sbt uses Ivy and there is thus no
test coverage for its implementation. Also note that the
DefaultResolutionCacheManager object created in
Update.configureResolutionCache now requires a reference to an
IvySettings object; DRCM expects this to be non-null.
The TestCaseGenerators uses global set for ensuring that certain generated
values are unique. This is not the best design because the more properties
you check the harder is to generate new sample inputs because of already
accumulated values. This results in:
[info] + Analysis.Simple Merge and Split: OK, proved property.
[info] ! Analysis.Complex Merge and Split: Gave up after only 8 passed tests. 93 tests were discarded.
I don't have an ambition to reduce the scope of this global set but at
least I wanted to make generators to work a bit harder on generating
samples.
Instead of using `suchThat` method for filtering out non-unique samples
we use `retryUntil` that never gives up (therefore it might not
terminate). We had to upgrade to latest (1.11.1) version of scalacheck
in order to have an access to `retryUntil` method.
Also, I overridden the `identifier` to delegate to original
`Gen.identifier` but with minimal size set to be to '3'. This means,
the generated identifier will be of size 3 or larger which is needed in
order to avoid collisions.
Fix the problem with unstable names synthesized for existential
types (declared with underscore syntax) by renaming type variables
to a scheme that is guaranteed to be stable no matter where given
the existential type appears.
The sheme we use are De Bruijn-like indices that capture both position
of type variable declarion within single existential type and nesting
level of nested existential type. This way we properly support nested
existential types by avoiding name clashes.
In general, we can perform renamings like that because type variables
declared in existential types are scoped to those types so the renaming
operation is local.
There's a specs2 unit test covering instability of existential types.
The test is included in compiler-interface project and the build
definition has been modified to enable building and executing tests
in compiler-interface project. Some dependencies has been modified:
* compiler-interface project depends on api project for testing
(test makes us of SameAPI)
* dependency on junit has been introduced because it's needed
for `@RunWith` annotation which declares that specs2 unit
test should be ran with JUnitRunner
SameAPI has been modified to expose a method that allows us to
compare two definitions.
This commit also adds `ScalaCompilerForUnitTesting` class that allows
to compile a piece of Scala code and inspect information recorded
callbacks defined in `AnalysisCallback` interface. That class uses
existing ConsoleLogger for logging. I considered doing the same for
ConsoleReporter. There's LoggingReporter defined which would fit our
usecase but it's defined in compile subproject that compiler-interface
doesn't depend on so we roll our own.
ScalaCompilerForUnit testing uses TestCallback from compiler-interface
subproject for recording information passed to callbacks. In order
to be able to access TestCallback from compiler-interface
subproject I had to tweak dependencies between interface and
compiler-interface so test classes from the former are visible in the
latter. I also modified the TestCallback itself to accumulate apis in
a HashMap instead of a buffer of tuples for easier lookup.
An integration test has been added which tests scenario
mentioned in #823.
This commit fixes#823.
The startup script should set sbt.cygwin=true if running from cygwin.
This will set the terminal type properly for JLine if not already set.
If sbt.cygwin=false or unset and os.name includes "windows", JAnsi is
downloaded by the launcher and installed on standard out/err.
The value for jline.terminal is transformed from explicit jline.X to
the basic types "windows", "unix", or "none". Now that sbt uses JLine
2.0, these types are understood by both sbt's JLine and Scala's.
Older Scala versions shaded the classes but not the terminal property
so both couldn't be configured with a class name at the same time.
It is no longer necessary for it to be loaded in a stable class loader
and line reading in the launcher does not require anything more advanced
than java.io.Console.readLine(String).
Scala versions 2.8 and later use the version that goes through JAnsi
and for that it is sufficient to have JNA in a stable loader.
Silencing boring warnings allows seeing the interesting ones. Here I've excluded
reflectiveCalls, since that's a useful warning.
However, silencing those warnings in *Eclipse* would require committing Eclipse
projects, something which *will* take extra effort; I verified that the warnings
disappeared from the output of compilation in SBT.
Eugene Yokota
Pierre DAL-PRA
Josh Suereth
Jean-Rémi Desjardins
Luc Bourlier
Grzegorz Kossakowski
Adriaan Moors
William Benton
Mark Harrah
Alex Dupre
Paolo G. Giarrusso