finish the sbt build

[SethTisue]

Let's put this to rest.

2.11 vs. 2.12

Might as well do it for 2.11 since it won't be any easier in a 2.12 context and merging it onto 2.12 won't be hard.

On 2.11.x, we should probably leave the ant build around, just for easy testing of suspected regressions. On 2.12.x, we should just delete the ant stuff.

Tasks (necessary)

• jline
• compare output with ant's (there's a task in the sbt build)
• update scripts/ directory
  • validate/publish-core
  • validate/test
    • junit
    • partest
    • respect scalac.args.optimise
    • additional test tasks:
      • port test.osgi
      • port test.bc
      • port test.sbt
      • port test.scaladoc
  • integrate/bootstrap
  • integrate/windows
  • minor scripts in tools directory
• Port stability verification to sbt
• community build uses the ant build to build scala
• integrate/windows script uses ant
• integrate/bootstrap script uses ant

Tasks (would be nice)

• REPL support (maybe done already? check)
• IntelliJ support out of the box (via custom ScalaInstance support/sbt task to generate project/include project files in root)

[SethTisue]

mass of random notes from the team meeting:

• Jason got stuck on JLine/JarJar stuff
  • possible fix: outsource it to a separate project.
    publish a JAR from that project, and pull it into scala/scala.
    (Adriaan has been working on some kind of refactoring making
    it only depend on scala-reflect? I didn't understand this.)
  • JarJar Links doesn't work on Java 8 bytecode
  • we currently use jarjar to also rewrite our own glue code
    that takes JLine. could we instead use a proxy or something?

how about a pure-Java interface to the REPL, with no dependencies,
like the sbt-test-interface? behind the Java facade we do reflection
or source rewriting or whatever.

Lukas and Jason say they don't use the sbt build yet, but it's mostly
out of habit. (Lukas doesn't need partest, and junit-only tests are
doable using the IntelliJ build.)

Being able to run the REPL of the Scala that we're building from sbt.
Maybe not strictly necessary; we can still run the REPL using the
script, like we do now. But we need to make sure JLine works in that
case.

Most of the work is moving over the Jenkins stuff and the release build.

There is a test where we diff the ant build products against the sbt
build products. I should keep doing that until we get rid of the ant
build entirely.

What about running the test suite? MiMa? OSGi?

there are some comments in the sbt build file itself with todos,
but there aren't any other writeups or anything like that.

Adriaan: "repl & jline separation -- some ongoing work here:
scala/scala@2.11.x...adriaanm:repflactor-jline-completion"

[SethTisue]

a big to-do list of Greg's: gkossakowski/scala#2

the big PR where the build was merged: scala/scala#4455

[retronym]

Here's my aborted attempt at incorporating jarjar for repl-jline: scala/scala#4593

[SethTisue]

several of @szeiger's additional PRs on this have already been merged. he's now working on Jenkins integration (w/ help from @adriaanm and me)

[SethTisue]

scala/scala#4884 is merged, which makes validate-publish-core use sbt, not ant. more scripts needing the same switch:

• validate/test
  • find a way to run partest --srcpath test/scaladoc (Hardcoded assumption about srcpath scala-partest-interface#14)
• integrate/bootstrap
• integrate/windows
• minor scripts in tools directory

[SethTisue]

@szeiger I can take on the scripts work. validate/test and integrate/windows should be easy-ish. integrate/bootstrap could be harder, but Adriaan and I can work on it together when I'm in SF Feb 8–12

[szeiger]

I just checked off some of the remaining tasks. Comparing the output of sbt and ant build can be done with https://github.com/typesafehub/scala-diff, JLine works in the sbt build. I haven't looked at the OSGi tests. They are not yet in the sbt build (unless partest or JUnit can run them).

validate/test should be straight-forward: Add a setup command that sets the Scala bootstrap version to the one from jenkins.properties and run the JUnit and partest tasks.

[retronym]

One thing I just noticed is that the integrate/bootstrap task will need to be updated to build the module scala-partest-interface.

I noticed this as I was using that script to build the modules and partest with my new STARR candidate, then trying to run partest through SBT.

[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: org.scala-lang.modules#scala-partest-interface_2.12.0-0b29927-nightly;0.5.0: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn]  Note: Unresolved dependencies path:
[warn]      org.scala-lang.modules:scala-partest-interface_2.12.0-0b29927-nightly:0.5.0 (/Users/jason/code/scala/build.sbt#L526)
[warn]        +- org.scala-lang:test:2.12.0-SNAPSHOT
[trace] Stack trace suppressed: run last test/*:update for the full output.
[error] (test/*:update) sbt.ResolveException: unresolved dependency: org.scala-lang.modules#scala-partest-interface_2.12.0-0b29927-nightly;0.5.0: not found
[error] Total time: 16 s, completed 03/02/2016 2:24:18 PM

[retronym]

Another minor task will be to output to ./build rather than ./build-sbt.

The history of using distinct names was to enable a diff of the products of the Ant and SBT builds. But I find the two directories to be inconvenient now for lots of little reasons (I need to edit my gitignore-s, my shell aliases that run build/quick/bin/* need to be duplicated, and so forth.

IMO, the time is right to default to "build".

[szeiger]

@retronym The scala-partest and scala-partest-interface versions in 2.12.x are wrong. Is there still a merge from 2.11.x outstanding?

[retronym]

Yes, we need to merge.