| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Also update a few example IDE files for Eclipse and IntelliJ.
This drops the dependency by integrating the bare minimum functionality
to keep things working.
|
| | |
|
| |
|
|
|
| |
The Scala Swing library will still ship with 2.11 (albeit unsupported).
It now resides at https://github.com/scala/scala-swing.
|
| |
|
|
|
| |
The continuations plugin and library will still ship with 2.11 (albeit unsupported).
They now reside at https://github.com/scala/scala-continuations.
|
| |
|
|
|
|
|
|
|
| |
That is, scaladoc is still in the scala-compiler artifact.
Let dbuild know so that it won't freak out.
ps: dbuild-meta.json should be kept in synch with
src/build/dbuild-meta-json-gen.scala until we can
automate that in the build
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These modules move to their own repositories:
- https://github.com/scala/scala-xml (v1.0-RC3)
- https://github.com/scala/scala-parser-combinators (v1.0-RC1)
The modularization depends on the new partest, as the old one's
classpath handling did not support a modularized scala.
The compiler pom now depends on the artifacts published separately,
with versions specified in versions.properties.
NOTES:
- The osgi tests resolve the xml and parsers jars and osgi-fy them,
as they are no longer built locally.
TODO: Can we move the osgification to the module builds?
- Disabled local repositories: don't want to accidentally include
unpublished artifacts in releases etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As partest is now resolved from maven, `test/partest` uses `ant test.suite.init`
to determine the classpath (serialized to build/pack/partest.properties)
that's necessary to run `scala.tools.partest.nest.ConsoleRunner`.
Thus, partest gets exactly the same classpath, whether run from
the command line through `test/partest` or via `ant test`.
The version of partest we're using is specified by
properties defined in versions.properties (formerly `starr.number`).
Currently, we're using:
```
scala.binary.version=2.11.0-M4
partest.version.number=1.0-RC3
```
NOTES:
- The version of Scala being tested must be backwards binary compatible with
the version of Scala that was used to compile partest.
- Once 2.11 goes final, `scala.binary.version=2.11`, and `starr.version=2.11.0`.
- Need scalacheck on classpath for test/partest scalacheck tests.
- Removed atrophied ant tests (haven't been run/changed for at least two years
I checked 81d659141a as a "random" sample).
- Removed scalacheck. It's resolved as a partest dependency.
- For now, use a locally built scalap
- Kept the trace macro in the main repo (partest-extras)
- New targets for faster pr validation: test-core-opt, test-stab-opt
- Reused partest eclipse/intellij project to partest-extras
(note: the partest dependency is hard-coded)
|
|
|
The next version of [dbuild](http://typesafehub.github.io/distributed-build/0.5.3/index.html)
will parse `dbuild-meta.json` to determine which jars are produced by a Scala build.
This way we can modularize without changing dbuild itself.
Yes, I know `dbuild-meta.json` should be generated during the build.
However, given the state of our build.xml, I think this is pointless.
My goal is to generate build.xml, dbuild-meta.json and Eclipse projects
from a higher-level description of our build. Baby steps...
Including improvements by @cunei:
- Removing outdated field "uri" from ExtractedBuildMeta
- Changed "partest" to "scala-partest" (the actual jar name)
|
