| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
- Intercept incorrect "binary conflict" warning issued by SBT.
Fixes https://github.com/scala/scala-dev/issues/100
- Bump to a new version of pantsbuild/jarjar to fix an
incompatibility with Java 8 parameter names in class
files, which we run into on the 2.12.x branch. See:
https://github.com/pantsbuild/jarjar/pull/19
- Disable info level logging for dependency resolve/download.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Shell scripts are generated with `mkBin` sbt task that calls ScalaTool.
ScalaTool is defined in project/ and is a port of Ant task that lives
in scala.tools.ant.ScalaTool. While porting, we've simplified the code
significantly.
The `mkBin` task is defined in a new subproject: dist. This subproject
will become responsible for building the distribution in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Difficult though it may be to accept, it must go. We couldn't keep it
working with active maintenance; after eight months of neglect there is
no chance. Nobody is working on it or using it. The code will remain in
the history if anyone wants it.
One of the most annoying experiences one can have when building a new
project is finding out one has been fiddling with an abandoned build
system which isn't even expected to work. Sometimes I check out a scala
project and there is a build.xml, a pom.xml, and a project directory.
We should not be among those who sow such build confusion.
|
| |
|
|
| |
Also fixed partest explosion that happened after partest redesign.
|
| |
|
|
| |
binary libs script anymore. Only pull is implemented.
|
| |
|
