Merge pull request #109 from phaller/master

Update scala-pickling build
Merge pull request #110 from phaller/master

Update scala-pickling build
fixes the paradise 2.11.x build, creates the 2.12.x build
Merge pull request #111 from xeno-by/master

fixes the paradise 2.11.x build, creates the 2.12.x build
tries to fix the run-macro-sbt-on-macro-paradise build
Merge pull request #112 from xeno-by/master

tries to fix the run-macro-sbt-on-macro-paradise build
allow passing compiler flags to scala-checkin
actually pass flags through ant to scalac
Scala 2.11.x now lives in eponymous branch
Use version hack for local build of scala-xml

Due to cycles between sbt's project resolver and external ones.
Same one was already in place for the full scala-xml modules build.
update to new credentials location
same cycle workaround for parsers as for xml
modules optional, no need for module bootstrap
Merge pull request #113 from phaller/master

Build scala-pickling-210 using Scala version 2.10.4
don't use empty versions...
publishModulesPrivate just to be sure
updates macro builds for 2.11.1
fixes run-macro-sbt builds (how did it work before?!)
Merge pull request #114 from xeno-by/master

updates macro builds for 2.11.1
Refactor scala-release-2.11.x as follows:

Determine Scala version as:
  1. $SCALA_VER_BASE$SCALA_VER_SUFFIX (if former variable is set)
  2. By parsing the tag (if HEAD is tagged as v$base$suffix)
  3. By parsing build.number for the base version, suffixing with -$sha-nightly

Serialize these versions to jenkins.properties, which are passed downstream to scala-release-2.11.x-dist.
This also removes the need to tag scala/scala-dist (not possible for nightlies, still encouraged for releases, but not a hard requirement).

Determine Module Versions
  - When running in "versions.properties" mode (the default), derive tags from these versions and build, publishing only those modules that are not available yet.
  - Otherwise, build HEAD for all modules, derive a -nightly version for them.

Bootstrap:
  1. Build minimal core of Scala as this version (aka locker), publish to private-repo
  2. Build modules required to bootstrap, publish to private-repo
  3. Build Scala using the previously built core and bootstrap modules, publish to private-repo
     This overwrites the minimal core on private-repo

Stage to sonatype (unless building a -nightly release):
  1. Stage this Scala build on sonatype
  2. Rebuild modules with this Scala build, and stage them on sonatype as well

This script can be run in multiple modes. It is design to work without any input,
so that it could be run in Travis CI. In that mode, it'll build a release when
the current HEAD of $SCALA_REF is tagged, and stage to sonatype. Otherwise,
it'll build a nightly.

Since the nightlies are intended to be a drop in replacement, all modules are built with the
full Scala version as their binary version, so that you can just set scalaVersion to the
nightly's sha-derived version and be good to go.

The other way to trigger a release is by setting the SCALA_VER_BASE env var.

By default, we build the versions of the modules as specified by versions.properties
(as specified in the $SCALA_REF commit). Set moduleVersioning to something random
to trigger building HEAD of each module, generating a fresh -$(git describe)-nightly version for each.

PS: set publishToSonatype to anything but "yes" to avoid publishing to sonatype
(publishing only done when $SCALA_REF's HEAD is tagged / SCALA_VER_BASE is set.)