| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- sbt requires a `default` configuration in the Scala distribution but
doesn’t publish such a configuration to Ivy repositories by default.
This is not a problem when publishing to a Maven repository because
Maven doesn’t use the concept of configurations and Ivy creates a
standard set (including `default`) when resolving artifacts from Maven
repositories, but it prevents the use of any Scala distribution
published with `publishLocal`.
The underlying issue is that sbt requires `default` instead of
`default(compile)`. We work around this limitation by publishing a
dummy `default` configuration.
- sbt has hardcoded dependencies on the `scala-library` artifact of type
`jar`. In the tradition of `sbt-osgi` we used type `bundle` when
publishing via Ivy but this makes the artifacts unusable from sbt. We
now publish the OSGi bundles directly as type `jar` (which is
compatible with how they appear in Ivy after resolving from a Maven
repository).
- We have to be more aggressive about not publishing certain
subprojects, otherwise `ivy.xml` files could still be published even
when using `publishArtifacts := false`.
- `removePomDependencies` now also modifies `ivy.xml` in addition to
the Maven POM so that bogus dependencies do not leak into the Ivy
descriptors.
Fixes https://github.com/scala/scala-dev/issues/130
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit conversions are now in package convert as ImplicitConversions,
ImplicitConversionsToScala and ImplicitConversionsToJava.
Deprecated WrapAsJava, WrapAsScala and the values in package object.
Improve documentation.
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
- 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.
|
|
|
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
|
