| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
merge/2.11.x-to-2.12.x-20160225
Conflicts:
scripts/jobs/integrate/bootstrap
src/build/maven/scala-actors-pom.xml
test/files/pos/t3420.flags
Conflicts were trivial to resolve.
|
| |\
| | |
| | | |
Typesafe is now Lightbend
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Which lets us remove the dependency on sbt-partest-interface,
as this has been incorporated into scala-partest itself.
Conflicts:
scripts/jobs/integrate/bootstrap
|
| |
| |
| |
| |
| | |
Which lets us remove the dependency on sbt-partest-interface,
as this has been incorporated into scala-partest itself.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/library/scala/collection/Iterator.scala
|
`-- trivial conflicts only. Parens were added to the
next() calls in 2.12.x, while in the meantime
`{Concat,Join}Iterator` were optimized in 2.11.x
|
| |
| |
| |
| |
| | |
Also refactor the partest parser to use the improved tab
completion for test paths.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We can complete partest options (I've excluded some that
aren't relevant in SBT), as well as test file names.
If `--srcpath scaladoc` is included, completion of test
paths will be based on `test/scaladoc` rather than
the default `test/files`. Note that the `--srcpath` option
is currently broken via scala partest interface, this
change to scala-partest is needed to make it work:
https://github.com/scala/scala-partest/pull/49
I've also hijacked the `--grep` option with logic
in the SBT command itself, rather than passing this
to `partest`. Just like `./bin/partest-ack`, this looks
for either test file names or regex matches within
the contents of test, check, or flag files.
I tried for some time to make the tab completion of
thousands of filenames more user friendly, but wasn't
able to get something working. Ideally, it should
only suggest to `test/files/{pos, neg, ...}` on the
first <TAB>, and then offer files on another TAB.
Files should also be offered if a full directory
has been entered. Hopefully a SBT parser guru will
step in and add some polish here.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The idea here is to avoid the need for switching
between the SBT shell and Bash.
- Add aliases for partest, scala{,c,p,doc}
- Change working directory for these forked processes
to the root project base directory, rather than the
subprojects base directory. This lets us use relative
paths to files in a more familar way.
- Don't log the output of forked processes with the
`[info] ` prefix, rather pass it through directly
to stdout.
Demo:
```
> partest --terse test/files/pos/t6231.scala
[info] Packaging /Users/jason/code/scala2/build-sbt/pack/lib/scala-partest-javaagent.jar ...
[info] Done packaging.
Selected 1 tests drawn from specified tests
.
[info] Passed: Total 1, Failed 0, Errors 0, Passed 1
[success] Total time: 3 s, completed 05/02/2016 12:44:19 PM
> scala sandbox/test.scala
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp sandbox/test.scala
Hello, World!
[success] Total time: 4 s, completed 05/02/2016 12:45:08 PM
> scalac sandbox/test.scala
[info] Running scala.tools.nsc.Main -usejavacp sandbox/test.scala
[success] Total time: 3 s, completed 05/02/2016 12:45:15 PM
> scala Test
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp Test
Hello, World!
[success] Total time: 1 s, completed 05/02/2016 12:45:20 PM
> scala
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp
Welcome to Scala 2.11.8-20160204-090931-42525ec (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_71).
Type in expressions for evaluation. Or try :help.
scala> 1.to
to toBinaryString toByte toChar toDegrees toDouble toFloat toHexString toInt toLong toOctalString toRadians toShort toString
scala> 1.toString
res0: String = 1
scala> :quit
[success] Total time: 8 s, completed 05/02/2016 12:45:48 PM
>
```
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
build.sbt
scripts/jobs/integrate/bootstrap
|
| |\
| | |
| | | |
sbt-based PR validation job
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
# Improve version handling in the sbt build:
The new settings `baseVersion` and `baseVersionSuffix` make it easier
to set version numbers for different kinds of builds in a consistent
way without e.g. having to first get a git SHA outside of sbt.
The new task `generateBuildCharacterPropertiesFile` writes the file
`buildcharacter.properties` to the root dir. The format is compatible
with the same file produced by the ANT build but it only contains a
subset of the properties, in particular the Maven version, which is
needed in publishing scripts and passed around between different
Jenkins jobs as `jenkins.properties`.
SHAs in version numbers are consistently shortened to 7 digits (as used
by git and github). Previously we used 7 digits in Maven snapshot
version numbers but 10 digits in canonical and OSGi version numbers.
# Add Jenkins script support to the sbt build:
The new command `setupPublishCore` takes the PR validation snapshot
repository as an argument and changes the required settings for the
`publish-core` build (use SHA-SNAPSHOT versioning, compile with
optimization enabled, do not publish scaladoc sets)
For example, the following command can be used to generate
`buildcharacter.properties` with the version numbers needed for PR
validation builds:
sbt setupPublishCore dummy generateBuildCharacterPropertiesFile
The sbt build will now automatically detect and use a “~/.credentials”
file with the credentials for publishing to a remote repository.
# Call sbt from `publish-core`:
The correct`$SBT_CMD` is set directly in `bootstrap` and used by
`publish-core` to first generate `buildcharacter.properties` and then
build and publish. Parsing the git revision, computing a version
number and getting binary dependencies are no longer required in the
script. This is all done in the sbt build.
|
| |/
| |
| |
| |
| | |
Instead of waiting for a Java-8-only build to use
`Files.setPosixPermissions()` we can call `setExecutable` and
`setReadable`, both of which are available on Java 6.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/backend/opt/ConstantOptimization.scala
src/compiler/scala/tools/nsc/transform/Constructors.scala
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/scaladoc/scala/tools/nsc/doc/html/page/Template.scala
src/scaladoc/scala/tools/nsc/doc/html/resource/lib/jquery.layout.js
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows partest to be run from the command line on the artifacts
produced by the sbt build. The actual location for partest.properties
is hardcoded in the partest script as build/pack/partest.properties.
This will have to be changed when we make sbt the default build tool.
To test this now you can manually copy the generated file from
build-sbt/quick/partest.properties to build/pack/partest.properties.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Fix the scoping of files/lib/*.jar. These files were not on the
classpath when running partest from sbt.
- Pass the same standard Java options to partest as from the command
line. This requires new versions of scala-partest and
scala-partest-interface.
- Fix the classpath scanning in jvm/innerClassEnclMethodJavaReflection.
It only worked for JARs and relative directories but not for absolute
directory paths (which are produced by sbt).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Create the directory for the output file when building an OSGi
bundle. Otherwise a publishing command would fail if dist/mkPack had
not been run before.
- Depend only on “packagedArtifact” in “mkPack”, not on “packageBin”.
The latter is sbt’s standard packaging task but some of the required
dependencies need to be packaged as OSGi bundles.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This replicates the results of `ant -Dlocker.skip=1 distpack` with the
following differences:
- The POM files produced by the ant build under dists/maven still
contain unresolved variables like `@VERSION@`. The ant build resolves
them in the actual publishing process. The sbt build generates the
correct version numbers directly.
- Scaladoc sets in the ant build are created with the scaladoc tool from
“quick”. The sbt build uses the STARR scaladoc.
- The scaladoc sets for scala-actors, scala-compiler, scala-reflect and
scalap from the ant build contain documentation for the classes
`Null`, `Nothing`, `Any` and `AnyRef`. The sbt build omits those
classes from all doc sets (except for scala-library, of course) under
the assumption that this is a bug in the ant build.
Other idiosyncracies of the ant build like declaring a packaging type of
`jar` (instead of `bundle`) for OSGi bundles, or using slightly
different module names and descriptions in scaladocs, OSGi bundles and
POMs, are reproduced faithfully for now.
Publishing from the sbt build is done in the usual sbt way. No actual
publishing targets are currently defined in the build. In order to test
stability of the publishing process, the `publishDists` task can be used
to publish to dists/maven-sbt with the same directory layout and naming
conventions employed by the ant build for publishing to dists/maven.
Source and binary JARs are OSGi-enabled. For the source JARs this is
done by hand-crafting the appropriate MANIFEST.MF entries (like the ant
build does). Binary JARs are packaged with BND, using the same outdated
BND version as the ant build for now to get identical results. We do not
use sbt-osgi because it depends on a newer version of BND (probably OK
to upgrade in the future) and does not allow a crucial bit of
configuration that we need: Setting the classpath for BND. In sbt-osgi
this is always `fullClasspath in Compile` whereas we really want
`products in Compile in packageBin` to keep things simple.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
- ManMaker is compiled in a new subproject “manual”. A simple command
line runner complements the ant task so that it can be run from sbt.
- Another new subproject “scala-dist” is responsible for building
the scala-dist.jar artifact.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This replicates the results of `ant -Dlocker.skip=1 distpack` with the
following differences:
- The POM files produced by the ant build under dists/maven still
contain unresolved variables like `@VERSION@`. The ant build resolves
them in the actual publishing process. The sbt build generates the
correct version numbers directly.
- Scaladoc sets in the ant build are created with the scaladoc tool from
“quick”. The sbt build uses the STARR scaladoc.
- The scaladoc sets for scala-actors, scala-compiler, scala-reflect and
scalap from the ant build contain documentation for the classes
`Null`, `Nothing`, `Any` and `AnyRef`. The sbt build omits those
classes from all doc sets (except for scala-library, of course) under
the assumption that this is a bug in the ant build.
Other idiosyncracies of the ant build like declaring a packaging type of
`jar` (instead of `bundle`) for OSGi bundles, or using slightly
different module names and descriptions in scaladocs, OSGi bundles and
POMs, are reproduced faithfully for now.
Publishing from the sbt build is done in the usual sbt way. No actual
publishing targets are currently defined in the build. In order to test
stability of the publishing process, the `publishDists` task can be used
to publish to dists/maven-sbt with the same directory layout and naming
conventions employed by the ant build for publishing to dists/maven.
Source and binary JARs are OSGi-enabled. For the source JARs this is
done by hand-crafting the appropriate MANIFEST.MF entries (like the ant
build does). Binary JARs are packaged with BND, using the same outdated
BND version as the ant build for now to get identical results. We do not
use sbt-osgi because it depends on a newer version of BND (probably OK
to upgrade in the future) and does not allow a crucial bit of
configuration that we need: Setting the classpath for BND. In sbt-osgi
this is always `fullClasspath in Compile` whereas we really want
`products in Compile in packageBin` to keep things simple.
Conflicts:
build.sbt
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- ManMaker is compiled in a new subproject “manual”. A simple command
line runner complements the ant task so that it can be run from sbt.
- Another new subproject “scala-dist” is responsible for building
the scala-dist.jar artifact.
Conflicts:
build.sbt
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Move version-related code into a separate VersionUtil object
- Fix the canonical version. The sbt build previously took the full
version including the suffix (plus timestamp and hash) whereas the ant
build uses the version without the suffix
- Include the version number in the generated scaladocs
- Add project descriptions and include them in the scaladocs (like the
ant build does)
- Add other missing scaladoc options to the sbt build
- Copy resources in all subprojects when building dist/mkQuick and
fix `includeFilter` settings to include all required files
|
| |
| |
| |
| |
| |
| |
| | |
- Docs for actors, compiler, library, reflect and scalap are built by
default. Generated artifacts are removed when cleaning the respective
subproject.
- Fix some exclude patterns for scaladoc sources in the ANT build
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Add dependencies for scala-swing, scala-continuations-library and
scala-continuations-plugin
- Build all JARs for “pack” in dist/packageBin
- Add “dist/mkQuick” task for building all required projects for
“quick” and creating the launcher scripts
- Add “dist/mkPack” task for packaging all required projects for
“pack” and creating the launcher scripts
- Include classes from “forkjoin” project in scala-library.jar
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reusing parts of #4593, this commits adds two additional subprojects to
the sbt build:
- repl-jline, which is already used by the ant build, builds the part of
the REPL that depends on JLine. The actual JLine depenency is moved to
this project.
- repl-jline-shaded uses JarJar to create a shaded version of repl-jline
and jline.jar.
Unlike the ant build, this setup does not use any circular dependencies.
dist/mkBin puts all of quick/repl, quick/repl-jline and
quick/repl-jline-shaded onto the classpath of build-sbt/quick/bin/scala.
A future addition to the sbt build for building build-sbt/pack will have
to put the generated classfiles into the correct JARs, mirroring the old
structure.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Set the correct unmanagedResourceDirectories for the compiler and
library projects. These projects already had includeFilter definitions
to copy the correct resource files to the target dirs but they were
meaningless without a source dir.
- Set a target path for ‘dist’ to make stream files go to the proper
.gitignored dir.
- Set permissions ugo+rx on all generated script and batch files.
|
|\| |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In preparation for use of the presentation compiler to drive
REPL tab completion, add a dependency in the build.
As far as the outside world is concerned, these are already comingled
in scala-compiler.jar, and this patch doesn't change that.
|
|\ \ \
| | |/
| |/| |
|
| | | |
|
| | |
| | |
| | |
| | | |
afaict, this was just an oversight
|
| |/
| |
| |
| |
| | |
Scala bootstrap version, ScalaCheck version should be the same
as the ant build.
|
|\| |
|
| |
| |
| |
| |
| | |
(just hitting the highlights here, not worrying yet about bumping the
dates in every modified source file)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Provide deprecated compatibility stubs for the types and static members,
which forward as follows:
```
scala.concurrent.forkjoin.ForkJoinPool => java.util.concurrent.ForkJoinPool
scala.concurrent.forkjoin.ForkJoinTask => java.util.concurrent.ForkJoinTask
scala.concurrent.forkjoin.ForkJoinWorkerThread => java.util.concurrent.ForkJoinWorkerThread
scala.concurrent.forkjoin.LinkedTransferQueue => java.util.concurrent.LinkedTransferQueue
scala.concurrent.forkjoin.RecursiveAction => java.util.concurrent.RecursiveAction
scala.concurrent.forkjoin.RecursiveTask => java.util.concurrent.RecursiveTask
scala.concurrent.forkjoin.ThreadLocalRandom => java.util.concurrent.ThreadLocalRandom
```
To prepare for Java 9, the Scala library does not itself use `sun.misc.Unsafe`.
However, for now, it provide a convenience accessor for it
via `scala.concurrent.util.Unsafe`. This (deprecated) class will
be removed as soon as the eco-system drops its use
(akka-actor, I'm looking at you).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
<h1>Allow mixed builds in ant</h1>
The `JFunction` classes depend on the `FunctionN` traits, so the
Java compiler needs the Scala library on the classpath.
At the same time, while compiling the Scala library, the symbols for
`JFunction` classes need to be available to emit indy-lambda closures.
Therefore we pass the `JFunctions` as Java sources while compiling the
Scala library.
<h1>Upgrade versions of osgi tools</h1>
Set the required java version in bnd files (JavaSE-1.8).
Introduce `scala-swing.version.osgi` as a quick hack to
allow manually deriving an osgi-friendly version number
for the `scala-swing.version.number`. The latter is used
to resolve the artifact, the osgi version is just so we
can generate a bundle that osgi will accept.
Bnd 1.50 doesn't work with Java 8 classfiles, so upgrade to 2.4.1.
Also upgrade all other tools to make tests pass.
For `org.eclipse.osgi` we moved to the group ID `org.eclipse.tycho`,
where there's a newer version available. The osgi tests would fail
with the most recent version available in the `org.eclipse.osgi` groupID.
The new version of bnd only copies *classfiles* from the
original into the resulting jar, while the old version also copied
all other files. This caused osgi test failure with a `NoClassDefFound`,
which was really due to a `NumberFormatException` in `ScalaVersion`,
as it couldn't find the properties file to parse the version in...
Include resources from source jar into osgi bundle as follows:
```
Include-Resource: @@SOURCE_JARNAME@
```
This makes bnd copy all resources from the source jar. I ran the
following on the osgi artifacts of this branch, and on 2.11.x:
```
for f in `find build/osgi -name '*.jar' -a -not -name '*src.jar'`; do unzip -l $f | grep -v '\.class' ; done
```
Comparing the two file lists, things look OK:
https://gist.github.com/lrytz/be08db051a53eded192d
|
|\| |
|
| |\
| | |
| | | |
Corral, shade & embed jline.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As usual, the repl will use whatever jline 2 jar on the classpath,
if there is one. Failing that, there's a fallback and an override.
If instantiating the standard `jline.InteractiveReader` fails,
we fall back to an embedded, shaded, version of jline,
provided by `jline_embedded.InteractiveReader`.
(Assume `import scala.tools.nsc.interpreter._` for this message.)
The instantiation of `InteractiveReader` eagerly exercises jline,
so that a linkage error will result if jline is missing or if the
provided one is not binary compatible.
The property `scala.repl.reader` overrides this behavior, if set to
the FQN of a class that looks like `YourInteractiveReader` below.
```
class YourInteractiveReader(completer: () => Completion) extends InteractiveReader
```
The repl logs which classes it tried to instantiate under `-Ydebug`.
# Changes to source & build
The core of the repl (`src/repl`) no longer depends on jline.
The jline interface is now in `src/repl-jline`.
The embedded jline + our interface to it are generated by the `quick.repl` target.
The build now also enforces that only `src/repl-jline` depends on jline.
The sources in `src/repl` are now sure to be independent of it,
though they do use reflection to instantiate a suitable subclass
of `InteractiveReader`, as explained above.
The `quick.repl` target builds the sources in `src/repl` and `src/repl-jline`,
producing a jar for the `repl-jline` classes, which is then transformed using
jarjar to obtain a shaded copy of the `scala.tools.nsc.interpreter.jline` package.
Jarjar is used to combine the `jline` jar and the `repl-jline` into a new jar,
rewriting package names as follows:
- `org.fusesource` -> `scala.tools.fusesource_embedded`
- `jline` -> `scala.tools.jline_embedded`
- `scala.tools.nsc.interpreter.jline` -> `scala.tools.nsc.interpreter.jline_embedded`
Classes not reachable from `scala.tools.**` are pruned, as well as empty dirs.
The classes in the `repl-jline` jar as well as those in the rewritten one
are copied to the repl's output directory.
PS: The sbt build is not updated, sorry.
PPS: A more recent fork of jarjar: https://github.com/shevek/jarjar.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Tell SBT to that we're forking an interactive process
- Automatically add `-usejavacp` so the REPL adds the classes
from the system classloader to the compilers classpath.
JLine seems to be working from within this setup.
```
% sbt
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=384m; support was removed in 8.0
[info] Loading global plugins from /Users/jason/.sbt/0.13/plugins
[info] Loading project definition from /Users/jason/code/scala2/project
[info] *** Welcome to the sbt build definition for Scala! ***
[info] This build definition has an EXPERIMENTAL status. If you are not
[info] interested in testing or working on the build itself, please use
[info] the Ant build definition for now. Check README.md for more information.
> repl/run
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp
Welcome to Scala version 2.11.6-SNAPSHOT-20150528-131650-70f0b1ded8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> 1 + 1
res0: Int = 2
(reverse-i-search)`1': 1 + 1
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Require Java 8 in ant build
- use -source 1.8 and -target 1.8 for javac
- Default scalac's -target to `jvm-1.8`, ignore and deprecate attempts
to use `jvm-1.{6.7}`
- Remove fragile javap-app test. The feature itself is slated for removal.
- Remove obsolete Java6 checkfile
- Adapt DCE tests
- Remove deprecated/redundant -target:jvm-1.6 from flags where the
intent was to trigger generation of stack map frames.
- Remove tests with -target:jvm-1.5 that tested without stack
map frames
- Ignore OpenJDK JVM warnings (via test/[files|scaladoc]/filters).
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added build configuration to ask SBT to forcible override the Scala
version in the subproject to the declared bootstrap version. I did
this in response to a warning by SBT the declared `scalaVersion`
has been evicted.
However, we actually *want* the newer version. To get rid of the
warning, we need to exclude all `"org.scala-lang" % "*"` when
depending on Scala modules. This cleanly breaks the cycle.
Here's a diff of `*/dependencyClasspath` as a result of this patch:
https://gist.github.com/retronym/217c76001b1b81798042
|
|
|
|
|
|
|
|
|
|
| |
Partest tests are defined in Integration configuration.
This means you need to run them with `test/it:test` command. We put them
in separate configuration because they are slow to run so user needs to
ask explicitly for partest to run.
Introduce a common way of setting jar location so it can be reused between
`scalaSubprojectSettings` and `partestJavaAgent`.
|
|
|
|
|
|
|
| |
Add dependency on scaladoc in junit subproject, as required by
6e6632e (it introduced a junit test for scaladoc).
Enable assertion stack traces and info logging of each test.
|