luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
sbt/build.sbt

1560 lines
66 KiB
Plaintext
Raw Normal View History

Factor out dependencies
2014-12-18 13:57:05 +01:00
import Dependencies._
Optimize build.sbt imports
2019-12-08 00:39:30 +01:00
import Util._
import com.typesafe.tools.mima.core.ProblemFilters._
import com.typesafe.tools.mima.core._
1.2.1-SNAPSHOT
2018-07-31 02:28:42 +02:00
import local.Scripted
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
import java.nio.file.{ Files, Path => JPath }
Optimize build.sbt imports
2019-12-08 00:39:30 +01:00
Don't rewrite RunFromSource.classpath every time In the sbt project, we often spuriously re-doc a number of projects that haven't changed because we modify a file in the resource path.
2019-07-27 21:47:00 +02:00
import scala.util.Try
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
lm-coursier 1.1.0-M14-2
2019-05-13 19:59:58 +02:00
ThisBuild / version := {
1.5.0-SNAPSHOT
2020-11-19 00:47:33 +01:00
val v = "1.5.0-SNAPSHOT"
lm-coursier 1.1.0-M14-2
2019-05-13 19:59:58 +02:00
nightlyVersion.getOrElse(v)
}
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
ThisBuild / version2_13 := "2.0.0-SNAPSHOT"
versionScheme
2020-10-04 06:09:15 +02:00
ThisBuild / versionScheme := Some("early-semver")
Reduce concurrency of scalafmtCheck Ref scalameta/scalafmt#1399
2019-05-17 20:51:07 +02:00
ThisBuild / scalafmtOnCompile := !(Global / insideCI).value
ThisBuild / Test / scalafmtOnCompile := !(Global / insideCI).value
Use turbo in sbt build
2019-08-31 22:37:01 +02:00
ThisBuild / turbo := true
Refactor remote cache to per-config Refactor remote caching to be scoped to configuration. In addition, this avoid the use of dependency resolver (since I'm not resolving anything) and directly invoke the Ivy resolver for the artifact, somewhat analogus to publishing process. This should speed up the `pullRemoteCache` since it avoids the POM download as well. For sbt-binrary-remote-cache this created a bit of complication since the (publishing) resolver doesn't act correctly as (downloading) resolver in terms of the credentials, so I had to create a new key `remoteCacheResolvers` to have asymmetric resolver.
2020-11-01 21:08:46 +01:00
ThisBuild / usePipelining := false // !(Global / insideCI).value
lm-coursier 1.1.0-M14-2
2019-05-13 19:59:58 +02:00
don't enable SemanticDB on CI Don't enable SemanticDB on CI for now since it doesn't support 2.10.
2021-01-10 21:26:26 +01:00
Global / semanticdbEnabled := !(Global / insideCI).value
Remove lint warnings in sbt build There were a number of unused key lint warnings when loading the sbt build. In the case of `fork in compile` and `crossVersion in update`, it wasn't clear that these were actually used, so I removed those settings. The others seemed to be used so I just added them to the exclude list. To make this work with legacy versions of sbt, I redefined the excludeLintKeys key. Once we update the build.properties to a 1.4.x version, we can drop the `val excludeLint` definition and replace `excludeLint` with `excludeLintKeys`. Side note: ++= does not work with excludeLintKeys which is why I used += for the excludes.
2020-07-19 18:43:51 +02:00
val excludeLint = SettingKey[Set[Def.KeyedInitialize[_]]]("excludeLintKeys")
Global / excludeLint := (Global / excludeLint).?.value.getOrElse(Set.empty)
Global / excludeLint += componentID
Global / excludeLint += whitesourceIgnoredScopes
Global / excludeLint += scriptedBufferLog
Global / excludeLint += checkPluginCross
Fix stamp-version for nightlies
2015-02-06 19:48:12 +01:00
// ThisBuild settings take lower precedence,
// but can be shared across the multi projects.
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
def buildLevelSettings: Seq[Setting[_]] =
inThisBuild(
Seq(
organization := "org.scala-sbt",
description := "sbt is an interactive build tool",
Use Bintray for nightly
2020-11-15 07:12:02 +01:00
bintrayPackage := sys.env.get("BINTRAY_PACKAGE").getOrElse("sbt"),
Update license url
2019-11-23 08:09:13 +01:00
licenses := List("Apache-2.0" -> url("https://github.com/sbt/sbt/blob/develop/LICENSE")),
Set java source and target levels Since sbt must run on jdk8, we should be setting the javac source and target levels.
2019-06-04 00:03:22 +02:00
javacOptions ++= Seq("-source", "1.8", "-target", "1.8"),
Compile / doc / javacOptions := Nil,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
developers := List(
Developer("harrah", "Mark Harrah", "@harrah", url("https://github.com/harrah")),
Developer("eed3si9n", "Eugene Yokota", "@eed3si9n", url("https://github.com/eed3si9n")),
Developer("jsuereth", "Josh Suereth", "@jsuereth", url("https://github.com/jsuereth")),
Developer("dwijnand", "Dale Wijnand", "@dwijnand", url("https://github.com/dwijnand")),
Add Ethan Atkins to developer list
2019-03-22 20:14:52 +01:00
Developer("eatkins", "Ethan Atkins", "@eatkins", url("https://github.com/eatkins")),
Format build.sbt
2018-01-26 15:19:14 +01:00
Developer(
"gkossakowski",
"Grzegorz Kossakowski",
"@gkossakowski",
url("https://github.com/gkossakowski")
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
Developer("Duhemm", "Martin Duhem", "@Duhemm", url("https://github.com/Duhemm"))
),
homepage := Some(url("https://github.com/sbt/sbt")),
scmInfo := Some(ScmInfo(url("https://github.com/sbt/sbt"), "git@github.com:sbt/sbt.git")),
sbt-scalafmt 1.3
2017-06-16 22:11:33 +02:00
resolvers += Resolver.mavenLocal,
format build.sbt
2019-05-11 09:42:06 +02:00
)
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
def commonBaseSettings: Seq[Setting[_]] = Def.settings(
format build.sbt
2019-05-11 09:42:06 +02:00
headerLicense := Some(
HeaderLicense.Custom(
"""|sbt
Apache License 2.0 https://discuss.lightbend.com/t/moving-sbt-and-zinc-to-the-apache-v2-license/1670
2018-09-14 09:38:58 +02:00
|Copyright 2011 - 2018, Lightbend, Inc.
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
|Copyright 2008 - 2010, Mark Harrah
Apache License 2.0 https://discuss.lightbend.com/t/moving-sbt-and-zinc-to-the-apache-v2-license/1670
2018-09-14 09:38:58 +02:00
|Licensed under Apache License 2.0 (see LICENSE)
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
|""".stripMargin
format build.sbt
2019-05-11 09:42:06 +02:00
)
),
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
scalaVersion := baseScalaVersion,
componentID := None,
Rename typesafe release resolver in sbt build I was still seeing a number of warnings in the sbt project itself in spite of 9bb88cd3427cc62d01185c7d356799ac044f766b. This made those go away.
2019-07-09 22:55:04 +02:00
resolvers += Resolver.typesafeIvyRepo("releases").withName("typesafe-sbt-build-ivy-releases"),
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
resolvers += Resolver.sonatypeRepo("snapshots"),
resolvers += "bintray-sbt-maven-releases" at "https://dl.bintray.com/sbt/maven-releases/",
Run scalafmtSbt Also add scalafmtSbtCheck to travis.
2019-11-30 23:18:41 +01:00
resolvers += Resolver.url(
"bintray-scala-hedgehog",
url("https://dl.bintray.com/hedgehogqa/scala-hedgehog")
)(Resolver.ivyStylePatterns),
Use hedgehog in ParseKey, Delegates, and ParserSpec test
2019-04-21 04:06:52 +02:00
testFrameworks += TestFramework("hedgehog.sbt.Framework"),
Refactor server test This refactors the server test to reuse the server instance for the tests against the same build.
2019-10-21 02:42:52 +02:00
testFrameworks += TestFramework("verify.runner.Framework"),
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
concurrentRestrictions in Global += Util.testExclusiveRestriction,
testOptions in Test += Tests.Argument(TestFrameworks.ScalaCheck, "-w", "1"),
testOptions in Test += Tests.Argument(TestFrameworks.ScalaCheck, "-verbosity", "2"),
javacOptions in compile ++= Seq("-Xlint", "-Xlint:-serial"),
use tag when available
2019-03-22 07:28:14 +01:00
Compile / doc / scalacOptions ++= {
import scala.sys.process._
val devnull = ProcessLogger(_ => ())
val tagOrSha = ("git describe --exact-match" #|| "git rev-parse HEAD").lineStream(devnull).head
add scalacOptions for scaladoc
2018-02-22 02:33:45 +01:00
Seq(
"-sourcepath",
(baseDirectory in LocalRootProject).value.getAbsolutePath,
"-doc-source-url",
use tag when available
2019-03-22 07:28:14 +01:00
s"https://github.com/sbt/sbt/tree/$tagOrSha€{FILE_PATH}.scala"
add scalacOptions for scaladoc
2018-02-22 02:33:45 +01:00
)
},
Add swoval java formatting plugin The swoval javafmt plugin uses the google java formatter (which I believe is the only widely used java formatter) to format source files. It does not provide an automatic javafmtOnCompile method like the scalafmt plugin so I had to manually implement that functionality. In general the java formatter is much faster than scalafmt so the impact of having javafmtOnCompile set to true is very low.
2020-01-14 23:01:17 +01:00
Compile / javafmtOnCompile := Def
.taskDyn(if ((scalafmtOnCompile).value) Compile / javafmt else Def.task(()))
.value,
Test / javafmtOnCompile := Def
.taskDyn(if ((Test / scalafmtOnCompile).value) Test / javafmt else Def.task(()))
.value,
Compile / unmanagedSources / inputFileStamps :=
(Compile / unmanagedSources / inputFileStamps).dependsOn(Compile / javafmtOnCompile).value,
Test / unmanagedSources / inputFileStamps :=
(Test / unmanagedSources / inputFileStamps).dependsOn(Test / javafmtOnCompile).value,
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
crossScalaVersions := List(scala212, scala213),
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
publishArtifact in Test := false,
Remove lint warnings in sbt build There were a number of unused key lint warnings when loading the sbt build. In the case of `fork in compile` and `crossVersion in update`, it wasn't clear that these were actually used, so I removed those settings. The others seemed to be used so I just added them to the exclude list. To make this work with legacy versions of sbt, I redefined the excludeLintKeys key. Once we update the build.properties to a 1.4.x version, we can drop the `val excludeLint` definition and replace `excludeLint` with `excludeLintKeys`. Side note: ++= does not work with excludeLintKeys which is why I used += for the excludes.
2020-07-19 18:43:51 +02:00
fork in run := true,
Use Def.settings in build.sbt
2018-02-01 15:53:05 +01:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
def commonSettings: Seq[Setting[_]] =
commonBaseSettings :+
Scala 2.12.13
2021-01-31 18:59:31 +01:00
addCompilerPlugin(kindProjector)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
def utilCommonSettings: Seq[Setting[_]] =
Use nowarn annotation
2021-02-07 02:13:37 +01:00
baseSettings :+ (crossScalaVersions := (scala212 :: scala213 :: Nil))
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
def minimalSettings: Seq[Setting[_]] =
Fix nightly publishing location by demoting publish-status to ThisBuild
2015-02-15 04:29:24 +01:00
commonSettings ++ customCommands ++
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
publishPomSettings ++ Release.javaVersionCheckSettings
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
def baseSettings: Seq[Setting[_]] =
Add Scalafmt
2017-04-20 01:56:35 +02:00
minimalSettings ++ Seq(projectComponent) ++ baseScalacOptions ++ Licensed.settings
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
def testedBaseSettings: Seq[Setting[_]] =
baseSettings ++ testDependencies
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
val sbt13Plus = Seq("1.3.0")
val sbt10Plus =
format build.sbt
2019-05-11 09:42:06 +02:00
Seq(
"1.0.0",
"1.0.1",
"1.0.2",
"1.0.3",
"1.0.4",
"1.1.0",
"1.1.1",
"1.1.2",
"1.1.3",
"1.1.4",
"1.1.5",
"1.1.6",
"1.2.0",
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
"1.2.1",
/*DOA,*/ "1.2.3",
"1.2.4",
/*DOA,*/ "1.2.6",
format build.sbt
2019-05-11 09:42:06 +02:00
"1.2.7",
"1.2.8",
) ++ sbt13Plus
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
val noUtilVersion =
Set("1.0.4", "1.1.4", "1.1.5", "1.1.6", "1.2.3", "1.2.4", "1.2.6", "1.2.7", "1.2.8")
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
val mimaSettings = mimaSettingsSince(sbt10Plus)
val utilMimaSettings = mimaSettingsSince(sbt10Plus.filterNot(noUtilVersion))
def mimaSettingsSince(versions: Seq[String]): Seq[Def.Setting[_]] = Def settings (
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
mimaPreviousArtifacts := {
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
val crossVersion = if (crossPaths.value) CrossVersion.binary else CrossVersion.disabled
versions.map(v => organization.value % moduleName.value % v cross crossVersion).toSet
Cleanup CommandChannel
2018-03-12 18:21:22 +01:00
},
mimaBinaryIssueFilters ++= Seq(
Fix the several typos detected by github.com/client9/misspell
2018-08-08 08:57:34 +02:00
// Changes in the internal package
Cleanup CommandChannel
2018-03-12 18:21:22 +01:00
exclude[DirectMissingMethodProblem]("sbt.internal.*"),
exclude[FinalClassProblem]("sbt.internal.*"),
exclude[FinalMethodProblem]("sbt.internal.*"),
exclude[IncompatibleResultTypeProblem]("sbt.internal.*"),
[sbt-server] LSP completions support
2018-10-02 16:51:20 +02:00
exclude[ReversedMissingMethodProblem]("sbt.internal.*")
Cleanup CommandChannel
2018-03-12 18:21:22 +01:00
),
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
val scriptedSbtReduxMimaSettings = Def.settings(mimaPreviousArtifacts := Set())
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val sbtRoot: Project = (project in file("."))
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
// .enablePlugins(ScriptedPlugin)
sbt 1.0.0-RC2
2017-07-20 04:00:42 +02:00
.aggregate(nonRoots: _*)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
buildLevelSettings,
minimalSettings,
add onLoadMessage
2018-10-05 09:04:22 +02:00
onLoadMessage := {
Print consistent version Java has dropped the leading "1." from the specification version in later versions. No one really refers to java 1.8, so it makes sense to strip the "1." from the suggested version.
2019-03-23 17:31:22 +01:00
val version = sys.props("java.specification.version")
add onLoadMessage
2018-10-05 09:04:22 +02:00
""" __ __
| _____/ /_ / /_
| / ___/ __ \/ __/
| (__ ) /_/ / /_
| /____/_.___/\__/
|Welcome to the build for sbt.
|""".stripMargin +
format build.sbt
2019-05-11 09:42:06 +02:00
(if (version != "1.8")
s"""!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Print consistent version Java has dropped the leading "1." from the specification version in later versions. No one really refers to java 1.8, so it makes sense to strip the "1." from the suggested version.
2019-03-23 17:31:22 +01:00
| Java version is $version. We recommend java 8.
add onLoadMessage
2018-10-05 09:04:22 +02:00
|!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!""".stripMargin
format build.sbt
2019-05-11 09:42:06 +02:00
else "")
add onLoadMessage
2018-10-05 09:04:22 +02:00
},
Upgrade to sbt-site 1.2.0
2017-05-08 15:34:41 +02:00
Util.baseScalacOptions,
Docs.settings,
scalacOptions += "-Ymacro-expand:none", // for both sxr and doc
Util.publishPomSettings,
otherRootSettings,
Transform.conscriptSettings(bundledLauncherProj),
Split proguarded launcher out to a subproject
2015-02-06 20:35:32 +01:00
publish := {},
Fix build to publish M6
2017-05-30 08:44:13 +02:00
publishLocal := {},
Merge branch '1.0.x' into wip/bump
2017-11-29 22:45:02 +01:00
skip in publish := true,
format build.sbt
2019-05-11 09:42:06 +02:00
commands in Global += Command
.single("sbtOn")((state, dir) => s"sbtProj/test:runMain sbt.RunFromSourceMain $dir" :: state),
Fix MiMa
2019-10-17 23:27:43 +02:00
mimaSettings,
in-source sbt-houserules
2019-10-20 06:41:53 +02:00
mimaPreviousArtifacts := Set.empty,
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
buildThinClient := (sbtClientProj / buildThinClient).evaluated,
buildNativeThinClient := (sbtClientProj / buildNativeThinClient).value,
installNativeThinClient := {
// nativeInstallDirectory can be set globally or in a gitignored local file
val dir = nativeInstallDirectory.?.value
val target = Def.spaceDelimited("").parsed.headOption match {
case Some(p) => file(p).toPath
case _ =>
dir match {
Rename to sbtn
2020-08-14 04:56:02 +02:00
case Some(d) => d / "sbtn"
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
case _ =>
val msg = "Expected input parameter <path>: installNativeExecutable /usr/local/bin"
throw new IllegalStateException(msg)
}
}
val base = baseDirectory.value.toPath
val exec = (sbtClientProj / buildNativeThinClient).value
streams.value.log.info(s"installing thin client ${base.relativize(exec)} to ${target}")
Files.copy(exec, target, java.nio.file.StandardCopyOption.REPLACE_EXISTING)
}
Migrate to using the sbt/launcher module, rather than having the code embedded. * Remove launch/* code/tests, as these are in the sbt/launcher project. * Create a new project which will resolve launcher module from sonatype-snapshots, and repackage it for the currently building version of sbt. * Remove ComponentManagerTest which was relying DIRECTLY on launcher classes. We'll need to reconfigure this shortly to enable the tests again. Remaining TODOs - * Update resolvers so people can find the launcher. * Add ComponentManagerTest back. * Re-publish the sbt-launch.jar in the location it used to be published.
2015-03-24 21:12:51 +01:00
)
// This is used to configure an sbt-launcher for this version of sbt.
lazy val bundledLauncherProj =
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
(project in file("launch"))
.settings(
minimalSettings,
inConfig(Compile)(Transform.configSettings),
Release.launcherSettings(sbtLaunchJar)
)
.enablePlugins(SbtLauncherPlugin)
.settings(
name := "sbt-launch",
moduleName := "sbt-launch",
description := "sbt application launcher",
autoScalaLibrary := false,
crossPaths := false,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
// mimaSettings, // TODO: Configure MiMa, deal with Proguard
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
publish := Release.deployLauncher.value,
publishLauncher := Release.deployLauncher.value,
Fix MiMa
2019-10-17 23:27:43 +02:00
packageBin in Compile := sbtLaunchJar.value,
mimaSettings,
mimaPreviousArtifacts := Set()
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Fix java version check, and use scope filter
2014-12-18 19:14:04 +01:00
/* ** subproject declarations ** */
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
val collectionProj = (project in file("internal") / "util-collection")
.settings(
testedBaseSettings,
Cross build collectionProj
2020-07-08 01:52:52 +02:00
utilCommonSettings,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
Util.keywordsSettings,
name := "Collections",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies ++= Seq(sjsonNewScalaJson.value),
Cross build collectionProj
2020-07-08 01:52:52 +02:00
libraryDependencies ++= (CrossVersion.partialVersion(scalaVersion.value) match {
case Some((2, major)) if major <= 12 => Seq()
case _ => Seq("org.scala-lang.modules" %% "scala-parallel-collections" % "0.2.0")
}),
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
implement tokenfile authentication
2017-09-22 05:05:48 +02:00
mimaBinaryIssueFilters ++= Seq(
// Added private[sbt] method to capture State attributes.
exclude[ReversedMissingMethodProblem]("sbt.internal.util.AttributeMap.setCond"),
Rewrite to inline syntax
2017-10-19 02:10:29 +02:00
// Dropped in favour of kind-projector's inline type lambda syntax
exclude[MissingClassProblem]("sbt.internal.util.TypeFunctions$P1of2"),
Rewrite to polymorphic function syntax
2017-10-20 00:19:16 +02:00
// Dropped in favour of kind-projector's polymorphic lambda literals
exclude[MissingClassProblem]("sbt.internal.util.Param"),
exclude[MissingClassProblem]("sbt.internal.util.Param$"),
Get rid of Fn1
2017-10-20 05:18:43 +02:00
// Dropped in favour of plain scala.Function, and its compose method
exclude[MissingClassProblem]("sbt.internal.util.Fn1"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.TypeFunctions.toFn1"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.Types.toFn1"),
Remove all warnings from collectionProj
2017-12-04 16:50:45 +01:00
// Instead of defining foldr in KList & overriding in KCons,
// it's now abstract in KList and defined in both KCons & KNil.
exclude[FinalMethodProblem]("sbt.internal.util.KNil.foldr"),
exclude[DirectAbstractMethodProblem]("sbt.internal.util.KList.foldr"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.internal.util.Init*.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.Settings0.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.EvaluateSettings#INode.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.TypeFunctions.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.EvaluateSettings.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.Settings.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.EvaluateSettings#MixedNode.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.EvaluateSettings#BindNode.this"),
Run scalafmtSbt Also add scalafmtSbtCheck to travis.
2019-11-30 23:18:41 +01:00
exclude[IncompatibleSignatureProblem](
"sbt.internal.util.EvaluateSettings#BindNode.dependsOn"
),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.internal.util.Types.some")
implement tokenfile authentication
2017-09-22 05:05:48 +02:00
),
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(utilPosition)
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
// Command line-related utilities.
val completeProj = (project in file("internal") / "util-complete")
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilControl, utilLogging)
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
.settings(
testedBaseSettings,
name := "Completion",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies += jline,
Support scala 2.13 console in thin client In order to make the console task work with scala 2.13 and the thin client, we need to provide a way for the scala repl to use an sbt provided jline3 terminal instead of the default terminal typically built by the repl. We also need to put jline 3 higher up in the classloading hierarchy to ensure that two versions of jline 3 are not loaded (which makes it impossible to share the sbt terminal with the scala terminal). One impact of this change is the decoupling of the version of jline-terminal used by the in process scala console and the version of jline-terminal specified by the scala version itself. It is possible to override this by setting the `useScalaReplJLine` flag to true. When that is set, the scala REPL will run in a fully isolated classloader. That will ensure that the versions are consistent. It will, however, for sure break the thin client and may interfere with the embedded shell ui. As part of this work, I also discovered that jline 3 Terminal.getSize is very slow. In jline 2, the terminal attributes were automatically cached with a timeout of, I think, 1 second so it wasn't a big deal to call Terminal.getAttributes. The getSize method in jline 3 is not cached and it shells out to run a tty command. This caused a significant performance regression in sbt because when progress is enabled, we call Terminal.getSize whenever we log any messages. I added caching of getSize at the TerminalImpl level to address this. The timeout is 1 second, which seems responsive enough for most use cases. We could also move the calculation onto a background thread and have it periodically updated, but that seems like overkill.
2020-07-20 19:12:04 +02:00
libraryDependencies += jline3Reader,
load .inputrc file I think jline2 automatically load ".inputrc" file. But jline3 changed behavior.
2020-10-14 08:28:55 +02:00
libraryDependencies += jline3Builtins,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
Fix bimcompat breakages in complete Fixes https://github.com/sbt/sbt/issues/4268
2018-07-16 04:28:55 +02:00
// Parser is used publicly, so we can't break bincompat.
mimaBinaryIssueFilters := Seq(
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[DirectMissingMethodProblem]("sbt.internal.util.complete.SoftInvalid.apply"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.complete.Invalid.apply"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.complete.Finite.apply"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.complete.Infinite.decrement"),
Fix bimcompat breakages in complete Fixes https://github.com/sbt/sbt/issues/4268
2018-07-16 04:28:55 +02:00
exclude[DirectMissingMethodProblem]("sbt.internal.util.complete.History.this"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.complete.Completion.suggestion"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.complete.Completion.token"),
mima
2019-11-22 20:37:07 +01:00
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.complete.Completion.displayOnly"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.complete.*"),
Remove all warnings from completeProj
2017-12-04 17:18:08 +01:00
),
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.configure(addSbtIO)
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
// A logic with restricted negation as failure for a unique, stable model
val logicProj = (project in file("internal") / "util-logic")
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilRelation)
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
.settings(
testedBaseSettings,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
name := "Logic",
mimaSettings,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
// defines Java structures used across Scala versions, such as the API structures and relationships extracted by
// the analysis compiler phases and passed back to sbt. The API structures are defined in a simple
// format from which Java sources are generated by the datatype generator Projproject
lazy val utilInterface = (project in file("internal") / "util-interface").settings(
utilCommonSettings,
Fix cross building of util-interface
2020-11-15 00:58:25 +01:00
crossScalaVersions := List(scala212),
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
javaOnlySettings,
crossPaths := false,
name := "Util Interface",
exportJars := true,
utilMimaSettings,
)
lazy val utilControl = (project in file("internal") / "util-control").settings(
utilCommonSettings,
name := "Util Control",
utilMimaSettings,
)
lazy val utilPosition = (project in file("internal") / "util-position")
.settings(
utilCommonSettings,
name := "Util Position",
scalacOptions += "-language:experimental.macros",
libraryDependencies ++= Seq(scalaReflect.value, scalatest % "test"),
utilMimaSettings,
)
lazy val utilLogging = (project in file("internal") / "util-logging")
.enablePlugins(ContrabandPlugin, JsonCodecPlugin)
Use a macro to create StringTypeTag instances Using the scala reflect library always introduces significant classloading overhead. We can eliminate the classloading overhead by generating StringTypeTags at compile time instead. This sped up average project loading time by a few hundred milliseconds on my computer. The ManagedLoggedReporter in zinc is still using the type tag based apis but after the next sbt release, we can upgrade the zinc apis. We also could consider breaking binary compatibility.
2020-07-29 23:55:19 +02:00
.dependsOn(utilInterface, collectionProj, coreMacrosProj)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.settings(
utilCommonSettings,
name := "Util Logging",
libraryDependencies ++=
Upgrade LineReader to JLine3 This commit upgrades sbt to using jline3. The advantage to jline3 is that it has a significantly better tab completion engine that is more similar to what you get from zsh or fish. The diff is bigger than I'd hoped because there are a number of behaviors that are different in jline3 vs jline2 in how the library consumes input streams and implements various features. I also was unable to remove jline2 because we need it for older versions of the scala console to work correctly with the thin client. As a result, the changes are largely additive. A good amount of this commit was in adding more protocol so that the remote client can forward its jline3 terminal information to the server. There were a number of minor changes that I made that either fixed outstanding ui bugs from #5620 or regressions due to differences between jline3 and jline2. The number one thing that caused problems is that the jline3 LineReader insists on using a NonBlockingInputStream. The implementation ofo NonBlockingInputStream seems buggy. Moreover, sbt internally uses a non blocking input stream for system in so jline is adding non blocking to an already non blocking stream, which is frustrating. A long term solution might be to consider insourcing LineReader.java from jline3 and just adapting it to use an sbt terminal rather than fighting with the jline3 api. This would also have the advantage of not conflicting with other versions of jline3. Even if we don't, we may want to shade jline3 if that is possible.
2020-06-30 17:57:57 +02:00
Seq(
jline,
Support scala 2.13 console in thin client In order to make the console task work with scala 2.13 and the thin client, we need to provide a way for the scala repl to use an sbt provided jline3 terminal instead of the default terminal typically built by the repl. We also need to put jline 3 higher up in the classloading hierarchy to ensure that two versions of jline 3 are not loaded (which makes it impossible to share the sbt terminal with the scala terminal). One impact of this change is the decoupling of the version of jline-terminal used by the in process scala console and the version of jline-terminal specified by the scala version itself. It is possible to override this by setting the `useScalaReplJLine` flag to true. When that is set, the scala REPL will run in a fully isolated classloader. That will ensure that the versions are consistent. It will, however, for sure break the thin client and may interfere with the embedded shell ui. As part of this work, I also discovered that jline 3 Terminal.getSize is very slow. In jline 2, the terminal attributes were automatically cached with a timeout of, I think, 1 second so it wasn't a big deal to call Terminal.getAttributes. The getSize method in jline 3 is not cached and it shells out to run a tty command. This caused a significant performance regression in sbt because when progress is enabled, we call Terminal.getSize whenever we log any messages. I added caching of getSize at the TerminalImpl level to address this. The timeout is 1 second, which seems responsive enough for most use cases. We could also move the calculation onto a background thread and have it periodically updated, but that seems like overkill.
2020-07-20 19:12:04 +02:00
jline3Terminal,
Use jline-terminal-jna for sbt server The old sbt launcher uses jansi 1.11, which is incompatible with jline3. To work around this, we can use the jna terminal implementation for the jline system terminal. This commit also switches to using the jline TerminalBuilder for all system terminals except for the windows system terminal with the thin client. The jline terminal builder uses reflection that is difficult to make work with the thin client and it is much easier to just manually construct the thin client. This is only necessary for windows because on posix the thin client will fall back to an implementation that shells out for stty commands.
2020-09-20 23:56:49 +02:00
jline3JNA,
Support scala 2.13 console in thin client In order to make the console task work with scala 2.13 and the thin client, we need to provide a way for the scala repl to use an sbt provided jline3 terminal instead of the default terminal typically built by the repl. We also need to put jline 3 higher up in the classloading hierarchy to ensure that two versions of jline 3 are not loaded (which makes it impossible to share the sbt terminal with the scala terminal). One impact of this change is the decoupling of the version of jline-terminal used by the in process scala console and the version of jline-terminal specified by the scala version itself. It is possible to override this by setting the `useScalaReplJLine` flag to true. When that is set, the scala REPL will run in a fully isolated classloader. That will ensure that the versions are consistent. It will, however, for sure break the thin client and may interfere with the embedded shell ui. As part of this work, I also discovered that jline 3 Terminal.getSize is very slow. In jline 2, the terminal attributes were automatically cached with a timeout of, I think, 1 second so it wasn't a big deal to call Terminal.getAttributes. The getSize method in jline 3 is not cached and it shells out to run a tty command. This caused a significant performance regression in sbt because when progress is enabled, we call Terminal.getSize whenever we log any messages. I added caching of getSize at the TerminalImpl level to address this. The timeout is 1 second, which seems responsive enough for most use cases. We could also move the calculation onto a background thread and have it periodically updated, but that seems like overkill.
2020-07-20 19:12:04 +02:00
jline3Jansi,
Upgrade LineReader to JLine3 This commit upgrades sbt to using jline3. The advantage to jline3 is that it has a significantly better tab completion engine that is more similar to what you get from zsh or fish. The diff is bigger than I'd hoped because there are a number of behaviors that are different in jline3 vs jline2 in how the library consumes input streams and implements various features. I also was unable to remove jline2 because we need it for older versions of the scala console to work correctly with the thin client. As a result, the changes are largely additive. A good amount of this commit was in adding more protocol so that the remote client can forward its jline3 terminal information to the server. There were a number of minor changes that I made that either fixed outstanding ui bugs from #5620 or regressions due to differences between jline3 and jline2. The number one thing that caused problems is that the jline3 LineReader insists on using a NonBlockingInputStream. The implementation ofo NonBlockingInputStream seems buggy. Moreover, sbt internally uses a non blocking input stream for system in so jline is adding non blocking to an already non blocking stream, which is frustrating. A long term solution might be to consider insourcing LineReader.java from jline3 and just adapting it to use an sbt terminal rather than fighting with the jline3 api. This would also have the advantage of not conflicting with other versions of jline3. Even if we don't, we may want to shade jline3 if that is possible.
2020-06-30 17:57:57 +02:00
log4jApi,
log4jCore,
disruptor,
sjsonNewScalaJson.value,
scalaReflect.value
),
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
libraryDependencies ++= Seq(scalacheck % "test", scalatest % "test"),
Compile / scalacOptions ++= (scalaVersion.value match {
case v if v.startsWith("2.12.") => List("-Ywarn-unused:-locals,-explicits,-privates")
case _ => List()
}),
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
Add utilLogging contraband directory to managedSourceDirectories See https://github.com/sbt/contraband/issues/76.
2019-12-13 03:10:45 +01:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
contrabandFormatsForType in generateContrabands in Compile := { tpe =>
val old = (contrabandFormatsForType in generateContrabands in Compile).value
val name = tpe.removeTypeParameters.name
if (name == "Throwable") Nil
else old(tpe)
},
utilMimaSettings,
mimaBinaryIssueFilters ++= Seq(
exclude[DirectMissingMethodProblem]("sbt.internal.util.SuccessEvent.copy*"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.TraceEvent.copy*"),
exclude[DirectMissingMethodProblem]("sbt.internal.util.StringEvent.copy*"),
// Private final class constructors changed
exclude[DirectMissingMethodProblem]("sbt.util.InterfaceUtil#ConcretePosition.this"),
exclude[DirectMissingMethodProblem]("sbt.util.InterfaceUtil#ConcreteProblem.this"),
exclude[ReversedMissingMethodProblem]("sbt.internal.util.ConsoleOut.flush"),
// This affects Scala 2.11 only it seems, so it's ok?
exclude[InheritedNewAbstractMethodProblem](
"sbt.internal.util.codec.JsonProtocol.LogOptionFormat"
),
exclude[InheritedNewAbstractMethodProblem](
"sbt.internal.util.codec.JsonProtocol.ProgressItemFormat"
),
exclude[InheritedNewAbstractMethodProblem](
"sbt.internal.util.codec.JsonProtocol.ProgressEventFormat"
),
Add internal multi logger implementation Prior to these changes, sbt was leaking large amounts of memory via log4j appenders. sbt has an unusual use case for log4j because it creates many ephemeral loggers while also having a global logger that is supposed to work for the duration of the sbt session. There is a lot of shared global state in log4j and properly cleaning up the ephemeral task appenders would break global logging. This commit fixes the behavior by introducing an alternate logging implementation. Users can still use the old log4j logging implementation but it will be off by default. The internal implementation is very simple: it just blocks the current thread and writes to all of the appenders. Nevertheless, I found the performance to be roughly identical to that of log4j in my sample project. As an experiment, I did the appending on a thread pool and got a significant performance improvement but I'll defer that to a later PR since parallel io is harder to reason about. Background: I was testing sbt performance in https://github.com/jtjeferreira/sbt-multi-module-sample and noticed that performance rapidly degraded after I ran compile a few times. I took a heap dump and it became obvious that sbt was leaking console appenders. Further investigation revealed that all of the leaking appenders in the project were coming from task streams. This made me think that the fix would be to track what loggers were created during task evaluation and clear them out when task evaluation completed. That almost worked except that log4j has an internal append only data structure containing logger names. Since we create unique logger names for each run, that internal data structure grew without bound. It looked like this could be worked around by creating a new log4j Configuration (where that data structure was stored) but while creating new configurations with each task runs did fix the leak, it also broke global logging, which was using a different configuration. At this point, I decided to write an alternate implementation of the appender api where I could be sure that the appenders were cleaned up without breaking global logging. Implementation: I made ConsoleAppender a trait and made it no longer extends log4j AbstractAppender. To do this, I had to remove the one log4j specific method, append(LogEvent). ConsoleAppender now has a method toLog4J that, in most cases, will return a log4j Appender that is almost identical to the Appenders that we previously used. To manage the loggers created during task evaluation, I introduce a new class, LoggerContext. The LoggerContext determines which logging backend to use and keeps track of what appenders and loggers have been created. We can create a fresh LoggerContext before each task evaluation and clear it out, cleaning up all of its resources after task evaluation concludes. In order to make this work, there were many places where we need to either pass in a LoggerContext or create a new one. The main magic is happening in the `next(State)` method in Main. This is where we create a new LoggerContext prior to command evaluation and clean it up after the evaluation completes. Users can toggle log4j using the new useLog4J key. They also can set the system property, sbt.log.uselog4j. The global logger will use the sbt internal implementation unless the system property is set. There are a fairly significant number of mima issues since I changed the type of ConsoleAppender. All of the mima changes were in the sbt.internal package so I think this should be ok. Effects: the memory leaks are gone. I successfully ran 5000 no-op compiles in the sbt-multi-module-sample above with no degradation of performace. There was a noticeable degradation after 30 no-op compiles before. During the refactor, I had to work on TestLogger and in doing so I also fixed https://github.com/sbt/sbt/issues/4480. This also should fix https://github.com/sbt/sbt/issues/4773
2020-08-05 20:23:35 +02:00
exclude[DirectMissingMethodProblem]("sbt.internal.util.MainAppender.*"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.BufferedAppender.*"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.ManagedLogger.this"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.ManagedLogger.this"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.MainAppender*"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.util.GlobalLogging.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.GlobalLogging.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.util.MainAppender*"),
exclude[MissingTypesProblem]("sbt.internal.util.ConsoleAppender"),
exclude[MissingTypesProblem]("sbt.internal.util.BufferedAppender"),
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
),
)
.configure(addSbtIO)
lazy val utilRelation = (project in file("internal") / "util-relation")
.settings(
utilCommonSettings,
name := "Util Relation",
libraryDependencies ++= Seq(scalacheck % "test"),
utilMimaSettings,
)
// Persisted caching based on sjson-new
lazy val utilCache = (project in file("util-cache"))
.settings(
utilCommonSettings,
name := "Util Cache",
libraryDependencies ++=
Seq(sjsonNewScalaJson.value, sjsonNewMurmurhash.value, scalaReflect.value),
libraryDependencies ++= Seq(scalatest % "test"),
utilMimaSettings,
mimaBinaryIssueFilters ++= Seq(
// Added a method to a sealed trait, technically not a problem for Scala
exclude[ReversedMissingMethodProblem]("sbt.util.HashFileInfo.hashArray"),
)
)
.configure(addSbtIO)
// Builds on cache to provide caching for filesystem-related operations
lazy val utilTracking = (project in file("util-tracking"))
.dependsOn(utilCache)
.settings(
utilCommonSettings,
name := "Util Tracking",
libraryDependencies ++= Seq(scalatest % "test"),
utilMimaSettings,
add context-bound-relaxed helpers for write-only Tracked
2020-04-24 11:53:38 +02:00
mimaBinaryIssueFilters ++= Seq(
// Private final class constructors changed
ProblemFilters.exclude[IncompatibleMethTypeProblem]("sbt.util.Tracked#CacheHelp.this"),
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
)
.configure(addSbtIO)
lazy val utilScripted = (project in file("internal") / "util-scripted")
.dependsOn(utilLogging, utilInterface)
.settings(
utilCommonSettings,
name := "Util Scripted",
build: Cleanup Dependencies
2020-01-10 14:41:55 +01:00
libraryDependencies += scalaParsers,
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
utilMimaSettings,
)
.configure(addSbtIO)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
/* **** Intermediate-level Modules **** */
// Runner for uniform test interface
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val testingProj = (project in file("testing"))
.enablePlugins(ContrabandPlugin, JsonCodecPlugin)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(testAgentProj, utilLogging)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
baseSettings,
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
name := "Testing",
build: Cleanup Dependencies
2020-01-10 14:41:55 +01:00
libraryDependencies ++= Seq(
scalaXml,
format build.sbt
2019-05-11 09:42:06 +02:00
testInterface,
launcherInterface,
sjsonNewScalaJson.value
),
-Xfatal-warnings in most subprojects
2018-09-18 17:47:55 +02:00
Compile / scalacOptions += "-Ywarn-unused:-locals,-explicits,-privates",
Fix #3062: Reduce red squiggles in Intellij This commit fixes most of the red squiggles created by the lack of analysis of Contraband-generated Scala files. It does not end with all the red squiggles but it substantially decreases the amount of them.
2017-04-19 07:50:18 +02:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
Send testing events to logger
2017-04-01 23:19:45 +02:00
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
contrabandFormatsForType in generateContrabands in Compile := ContrabandConfig.getFormats,
mimaSettings,
mima
2018-03-07 21:31:24 +01:00
mimaBinaryIssueFilters ++= Seq(
// private[sbt]
Merge branch 'wip/bumpsbt' into wip/merge-1.1.x
2018-03-27 15:12:01 +02:00
exclude[IncompatibleMethTypeProblem]("sbt.TestStatus.write"),
exclude[IncompatibleResultTypeProblem]("sbt.TestStatus.read"),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
// copy method was never meant to be public
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.EndTestGroupErrorEvent.copy"),
format build.sbt
2019-05-11 09:42:06 +02:00
exclude[DirectMissingMethodProblem](
"sbt.protocol.testing.EndTestGroupErrorEvent.copy$default$*"
),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.EndTestGroupEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.EndTestGroupEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.StartTestGroupEvent.copy"),
format build.sbt
2019-05-11 09:42:06 +02:00
exclude[DirectMissingMethodProblem](
"sbt.protocol.testing.StartTestGroupEvent.copy$default$*"
),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestCompleteEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestCompleteEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestInitEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestItemDetail.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestItemDetail.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestItemEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestItemEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestStringEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.testing.TestStringEvent.copy$default$1"),
Remove usage of DynamicVariable and fix memory leak, fixes https://github.com/sbt/sbt/issues/4112
2018-04-23 19:46:08 +02:00
//no reason to use
exclude[DirectMissingMethodProblem]("sbt.JUnitXmlTestsListener.testSuite"),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.configure(addSbtIO, addSbtCompilerClasspath)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Testing agent for running tests in a separate process.
Replace previous scalafmt plugin by neo-scalafmt The previous scalafmt plugin had two problems: * Caching with Coursier did not work correctly * It failed after the upgrade to 1.0 in my computer (from a clean fork): ``` [error] (testingProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (runProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (taskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (stdTaskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (actionsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (protocolProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (commandProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (mainSettingsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (mainProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (sbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (scriptedPluginProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (scriptedSbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] Total time: 19 s, completed May 24, 2017 10:44:56 AM ``` This commit replaces the previous scalafmt integration by the one created by Lucidsoftware, big shoutout! (/cc @pauldraper) https://github.com/lucidsoftware/neo-sbt-scalafmt
2017-05-24 11:15:22 +02:00
lazy val testAgentProj = (project in file("testing") / "agent")
.settings(
minimalSettings,
crossScalaVersions := Seq(baseScalaVersion),
crossPaths := false,
autoScalaLibrary := false,
name := "Test Agent",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies += testInterface,
mimaSettings,
Replace previous scalafmt plugin by neo-scalafmt The previous scalafmt plugin had two problems: * Caching with Coursier did not work correctly * It failed after the upgrade to 1.0 in my computer (from a clean fork): ``` [error] (testingProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (runProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (taskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (stdTaskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (actionsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (protocolProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (commandProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (mainSettingsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (mainProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (sbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (scriptedPluginProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] (scriptedSbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$ [error] Total time: 19 s, completed May 24, 2017 10:44:56 AM ``` This commit replaces the previous scalafmt integration by the one created by Lucidsoftware, big shoutout! (/cc @pauldraper) https://github.com/lucidsoftware/neo-sbt-scalafmt
2017-05-24 11:15:22 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Basic task engine
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val taskProj = (project in file("tasks"))
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilControl)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
name := "Tasks",
mimaSettings,
Util 1.3.0-M5
2019-03-08 21:26:15 +01:00
mimaBinaryIssueFilters ++= Seq(
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.Triggers.this"),
exclude[IncompatibleSignatureProblem]("sbt.Triggers.runBefore"),
exclude[IncompatibleSignatureProblem]("sbt.Triggers.injectFor"),
exclude[IncompatibleSignatureProblem]("sbt.Triggers.onComplete"),
exclude[DirectMissingMethodProblem]("sbt.Inc.apply"),
open up ExecuteProgress, and adds a few keys Fixes #4461 This opens up ExecuteProgress API that's been around under private[sbt]. Since the state passing mechanism hasn't been used, I got rid of it. The build user can configure the build using two keys Boolean `taskProgress` and `State => Seq[TaskProgress]` `progressReports`. `useSuperShell` is lightweight key on/off switch for the super shell that can be used as follows: ```scala Global / SettingKey[Boolean]("useSuperShell") := false ```
2019-03-18 02:17:39 +01:00
// ok because sbt.ExecuteProgress has been under private[sbt]
exclude[IncompatibleResultTypeProblem]("sbt.ExecuteProgress.initial"),
exclude[DirectMissingMethodProblem]("sbt.ExecuteProgress.*"),
exclude[ReversedMissingMethodProblem]("sbt.ExecuteProgress.*"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.ExecuteProgress.*"),
// ok because sbt.Execute has been under private[sbt]
exclude[IncompatibleSignatureProblem]("sbt.Execute.*"),
exclude[IncompatibleSignatureProblem]("sbt.Execute#CyclicException.*"),
exclude[IncompatibleSignatureProblem]("sbt.NodeView.*"),
Util 1.3.0-M5
2019-03-08 21:26:15 +01:00
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Standard task system. This provides map, flatMap, join, and more on top of the basic task model.
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val stdTaskProj = (project in file("tasks-standard"))
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilLogging, utilCache)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.dependsOn(taskProj % "compile;test->test")
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
name := "Task System",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
testExclusive,
mimaSettings,
Remove unused Task#mapTask
2019-05-29 15:43:14 +02:00
mimaBinaryIssueFilters ++= Seq(
// unused private[sbt]
exclude[DirectMissingMethodProblem]("sbt.Task.mapTask"),
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.configure(addSbtIO)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Embedded Scala code runner
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val runProj = (project in file("run"))
sbt-scalafmt 1.3
2017-06-16 22:11:33 +02:00
.enablePlugins(ContrabandPlugin)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilLogging, utilControl)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
migrate ForkOptions to Contraband
2017-05-12 00:33:12 +02:00
name := "Run",
-Xfatal-warnings in most subprojects
2018-09-18 17:47:55 +02:00
Compile / scalacOptions += "-Ywarn-unused:-locals,-explicits,-privates",
migrate ForkOptions to Contraband
2017-05-12 00:33:12 +02:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
mimaSettings,
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
mimaBinaryIssueFilters ++= Seq(
// copy method was never meant to be public
exclude[DirectMissingMethodProblem]("sbt.ForkOptions.copy"),
exclude[DirectMissingMethodProblem]("sbt.ForkOptions.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#BufferedOutput.copy"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#BufferedOutput.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#CustomOutput.copy"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#CustomOutput.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#LoggedOutput.copy"),
exclude[DirectMissingMethodProblem]("sbt.OutputStrategy#LoggedOutput.copy$default$*"),
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.configure(addSbtIO, addSbtCompilerClasspath)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Try RunFromSourceBasedRemoteSbtCreator
2018-02-01 15:53:11 +01:00
val sbtProjDepsCompileScopeFilter =
format build.sbt
2019-05-11 09:42:06 +02:00
ScopeFilter(
inDependencies(LocalProject("sbtProj"), includeRoot = false),
inConfigurations(Compile)
)
Try RunFromSourceBasedRemoteSbtCreator
2018-02-01 15:53:11 +01:00
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
lazy val scriptedSbtReduxProj = (project in file("scripted-sbt-redux"))
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
.dependsOn(sbtProj % "compile;test->test", commandProj, utilLogging, utilScripted)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
baseSettings,
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
name := "Scripted sbt Redux",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies ++= Seq(launcherInterface % "provided"),
mimaSettings,
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
scriptedSbtReduxMimaSettings,
)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.configure(addSbtIO, addSbtCompilerInterface, addSbtLmCore)
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
lazy val scriptedSbtOldProj = (project in file("scripted-sbt-old"))
.dependsOn(scriptedSbtReduxProj)
.settings(
baseSettings,
name := "Scripted sbt",
mimaSettings,
Work around package name confusion This works around the name conflict between sbt.test package and sbt.Keys.test. 1. sbt.test package is renamed to sbt.scriptedtest. This allows 1.0 plugins and builds to use `test` to mean `Keys.test`. 2. To keep binary compatibility for sbt 0.13 scripted, I am adding `sbt.test.ScriptedRunner` and `sbt.test.ScriptedTests` in `scripted-plugin` artifact. 3. Another affected user is Giter8 plugin that uses ScriptedPlugin. Since the intereactions are limited to `sbt.ScriptedPlugin.*`, we should be fine here. - https://github.com/foundweekends/giter8/blob/v0.11.0-M2/plugin/src/main/scala-sbt-1.0/giter8/SBTCompat.scala
2018-01-13 23:08:48 +01:00
mimaBinaryIssueFilters ++= Seq(
// sbt.test package is renamed to sbt.scriptedtest.
exclude[MissingClassProblem]("sbt.test.*"),
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
exclude[DirectMissingMethodProblem]("sbt.test.*"),
exclude[IncompatibleMethTypeProblem]("sbt.test.*"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.test.*"),
Work around package name confusion This works around the name conflict between sbt.test package and sbt.Keys.test. 1. sbt.test package is renamed to sbt.scriptedtest. This allows 1.0 plugins and builds to use `test` to mean `Keys.test`. 2. To keep binary compatibility for sbt 0.13 scripted, I am adding `sbt.test.ScriptedRunner` and `sbt.test.ScriptedTests` in `scripted-plugin` artifact. 3. Another affected user is Giter8 plugin that uses ScriptedPlugin. Since the intereactions are limited to `sbt.ScriptedPlugin.*`, we should be fine here. - https://github.com/foundweekends/giter8/blob/v0.11.0-M2/plugin/src/main/scala-sbt-1.0/giter8/SBTCompat.scala
2018-01-13 23:08:48 +01:00
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
lazy val scriptedPluginProj = (project in file("scripted-plugin"))
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
baseSettings,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
name := "Scripted Plugin",
mimaSettings,
Add SbtPlugin Fixes #3538 This brings in `sbt.ScriptedPlugin` as `sbt.plugins.ScriptedPlugin` into sbt mothership. In addition, `sbt.plugins.SbtPlugin` is added that enables the scripted plugin and `sbtPlugin := true`. This allows plugin authors to bring in scripted plugin by writing: ```scala lazy val root = (project in file(".")) .enablePlugins(SbtPlugin) ```
2018-01-13 20:28:06 +01:00
mimaBinaryIssueFilters ++= Seq(
Work around package name confusion This works around the name conflict between sbt.test package and sbt.Keys.test. 1. sbt.test package is renamed to sbt.scriptedtest. This allows 1.0 plugins and builds to use `test` to mean `Keys.test`. 2. To keep binary compatibility for sbt 0.13 scripted, I am adding `sbt.test.ScriptedRunner` and `sbt.test.ScriptedTests` in `scripted-plugin` artifact. 3. Another affected user is Giter8 plugin that uses ScriptedPlugin. Since the intereactions are limited to `sbt.ScriptedPlugin.*`, we should be fine here. - https://github.com/foundweekends/giter8/blob/v0.11.0-M2/plugin/src/main/scala-sbt-1.0/giter8/SBTCompat.scala
2018-01-13 23:08:48 +01:00
// scripted plugin has moved into sbt mothership.
exclude[MissingClassProblem]("sbt.ScriptedPlugin*")
Add SbtPlugin Fixes #3538 This brings in `sbt.ScriptedPlugin` as `sbt.plugins.ScriptedPlugin` into sbt mothership. In addition, `sbt.plugins.SbtPlugin` is added that enables the scripted plugin and `sbtPlugin := true`. This allows plugin authors to bring in scripted plugin by writing: ```scala lazy val root = (project in file(".")) .enablePlugins(SbtPlugin) ```
2018-01-13 20:28:06 +01:00
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Split to MiniDependencyTreePlugin Ref https://github.com/sbt/sbt/pull/5880 This split the dependency-graph plugin into MiniDependencyTreePlugin and DependencyTreePlugin.
2020-09-23 03:21:01 +02:00
lazy val dependencyTreeProj = (project in file("dependency-tree"))
.dependsOn(sbtProj)
.settings(
sbtPlugin := true,
baseSettings,
name := "sbt-dependency-tree",
Publish sbt-dependency-tree Maven style
2020-09-23 06:42:14 +02:00
publishMavenStyle := true,
Split to MiniDependencyTreePlugin Ref https://github.com/sbt/sbt/pull/5880 This split the dependency-graph plugin into MiniDependencyTreePlugin and DependencyTreePlugin.
2020-09-23 03:21:01 +02:00
// mimaSettings,
Mima
2020-09-23 03:47:38 +02:00
mimaPreviousArtifacts := Set.empty,
Split to MiniDependencyTreePlugin Ref https://github.com/sbt/sbt/pull/5880 This split the dependency-graph plugin into MiniDependencyTreePlugin and DependencyTreePlugin.
2020-09-23 03:21:01 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Implementation and support code for defining actions.
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val actionsProj = (project in file("main-actions"))
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(
completeProj,
runProj,
stdTaskProj,
taskProj,
testingProj,
utilLogging,
utilRelation,
utilTracking,
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
-sbinary/+sjson-new, -datatype/+contraband & upgrades * start to replace sbinary with sjson-new * upgrade from sbt/datatype to sbt/contraband * upgrade and migrate to new sbt modules APIs
2016-11-30 14:42:51 +01:00
name := "Actions",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies += sjsonNewScalaJson.value,
Support scala 2.13 console in thin client In order to make the console task work with scala 2.13 and the thin client, we need to provide a way for the scala repl to use an sbt provided jline3 terminal instead of the default terminal typically built by the repl. We also need to put jline 3 higher up in the classloading hierarchy to ensure that two versions of jline 3 are not loaded (which makes it impossible to share the sbt terminal with the scala terminal). One impact of this change is the decoupling of the version of jline-terminal used by the in process scala console and the version of jline-terminal specified by the scala version itself. It is possible to override this by setting the `useScalaReplJLine` flag to true. When that is set, the scala REPL will run in a fully isolated classloader. That will ensure that the versions are consistent. It will, however, for sure break the thin client and may interfere with the embedded shell ui. As part of this work, I also discovered that jline 3 Terminal.getSize is very slow. In jline 2, the terminal attributes were automatically cached with a timeout of, I think, 1 second so it wasn't a big deal to call Terminal.getAttributes. The getSize method in jline 3 is not cached and it shells out to run a tty command. This caused a significant performance regression in sbt because when progress is enabled, we call Terminal.getSize whenever we log any messages. I added caching of getSize at the TerminalImpl level to address this. The timeout is 1 second, which seems responsive enough for most use cases. We could also move the calculation onto a background thread and have it periodically updated, but that seems like overkill.
2020-07-20 19:12:04 +02:00
libraryDependencies += jline3Terminal,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
Remove all warnings from actionsProj
2017-12-05 17:16:26 +01:00
mimaBinaryIssueFilters ++= Seq(
// Removed unused private[sbt] nested class
exclude[MissingClassProblem]("sbt.Doc$Scaladoc"),
// Removed no longer used private[sbt] method
exclude[DirectMissingMethodProblem]("sbt.Doc.generate"),
perf: optimize hash for build This hot path was discovered by retronym using FlameGraph. This removes intermediate creation of Array. `filesModifiedBytes` in particular was bad as it was going through all `*.class` files, each generating an Array. This replaces that with `fileModifiedHash` that accepts `MessageDigest`. According to the flamegraph, evalCommon footprint reduced from 4.5% to 3.6%. Using `time sbt reload reload reload exit`, the median reduced from 41.450s to 39.467s.
2018-04-05 08:14:00 +02:00
exclude[DirectMissingMethodProblem]("sbt.compiler.Eval.filesModifiedBytes"),
exclude[DirectMissingMethodProblem]("sbt.compiler.Eval.fileModifiedBytes"),
Remove all warnings from actionsProj
2017-12-05 17:16:26 +01:00
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
.configure(
addSbtIO,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
addSbtCompilerInterface,
addSbtCompilerClasspath,
addSbtCompilerApiInfo,
Adapt to new library management API
2017-07-16 00:09:40 +02:00
addSbtLmCore,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
addSbtZinc
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
lazy val protocolProj = (project in file("protocol"))
sbt-scalafmt 1.3
2017-06-16 22:11:33 +02:00
.enablePlugins(ContrabandPlugin, JsonCodecPlugin)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(collectionProj, utilLogging)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Update to Contraband
2016-12-01 09:14:07 +01:00
testedBaseSettings,
name := "Protocol",
Use ipcsocket
2018-01-30 06:43:30 +01:00
libraryDependencies ++= Seq(sjsonNewScalaJson.value, ipcSocket),
-Xfatal-warnings in most subprojects
2018-09-18 17:47:55 +02:00
Compile / scalacOptions += "-Ywarn-unused:-locals,-explicits,-privates",
Fix #3062: Reduce red squiggles in Intellij This commit fixes most of the red squiggles created by the lack of analysis of Contraband-generated Scala files. It does not end with all the red squiggles but it substantially decreases the amount of them.
2017-04-19 07:50:18 +02:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
Switch SettingQueryResponse to JValue, implement JValueFormat
2017-03-20 17:44:57 +01:00
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
contrabandFormatsForType in generateContrabands in Compile := ContrabandConfig.getFormats,
mimaSettings,
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
mimaBinaryIssueFilters ++= Seq(
// copy method was never meant to be public
exclude[DirectMissingMethodProblem]("sbt.protocol.ChannelAcceptedEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ChannelAcceptedEvent.copy$default$1"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecCommand.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecCommand.copy$default$1"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecCommand.copy$default$2"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecStatusEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecStatusEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecutionEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.ExecutionEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.InitCommand.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.InitCommand.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.LogEvent.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.LogEvent.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQuery.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQuery.copy$default$1"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQueryFailure.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQueryFailure.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQuerySuccess.copy"),
exclude[DirectMissingMethodProblem]("sbt.protocol.SettingQuerySuccess.copy$default$*"),
evict some mima errors in sbt.internal
2020-05-12 17:34:34 +02:00
// ignore missing or incompatible methods in sbt.internal
exclude[IncompatibleMethTypeProblem]("sbt.internal.*"),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
exclude[DirectMissingMethodProblem]("sbt.internal.*"),
Add State extension Fixes https://github.com/sbt/sbt/issues/3112 This unpacks Extracted as State's extension methods. In addition this provides a way of responding via LSP.
2019-10-21 04:33:02 +02:00
exclude[MissingTypesProblem]("sbt.internal.protocol.JsonRpcResponseError"),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Update to Contraband
2016-12-01 09:14:07 +01:00
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// General command support and core commands not specific to a build system
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val commandProj = (project in file("main-command"))
sbt-scalafmt 1.3
2017-06-16 22:11:33 +02:00
.enablePlugins(ContrabandPlugin, JsonCodecPlugin)
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(protocolProj, completeProj, utilLogging)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
Start using launcher interface from sbt/launcher module.
2015-03-24 16:14:13 +01:00
name := "Command",
Remove JNA from sbt/sbt There's a conflict in JNA version difference between sbt and IO. Fixes #3821
2017-12-19 06:44:31 +01:00
libraryDependencies ++= Seq(launcherInterface, sjsonNewScalaJson.value, templateResolverApi),
-Xfatal-warnings in most subprojects
2018-09-18 17:47:55 +02:00
Compile / scalacOptions += "-Ywarn-unused:-locals,-explicits,-privates",
Fix #3062: Reduce red squiggles in Intellij This commit fixes most of the red squiggles created by the lack of analysis of Contraband-generated Scala files. It does not end with all the red squiggles but it substantially decreases the amount of them.
2017-04-19 07:50:18 +02:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
-sbinary/+sjson-new, -datatype/+contraband & upgrades * start to replace sbinary with sjson-new * upgrade from sbt/datatype to sbt/contraband * upgrade and migrate to new sbt modules APIs
2016-11-30 14:42:51 +01:00
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
contrabandFormatsForType in generateContrabands in Compile := ContrabandConfig.getFormats,
mimaSettings,
JSON port file This implements JSON-based port file. Thoughout the lifetime of the sbt server there will be `cwd / "project" / "target" / "active.json"`, which contains `url` field. Using this `url` the potential client, such as IDEs can find out which port number to hit. Ref #3508
2017-09-18 01:08:45 +02:00
mimaBinaryIssueFilters ++= Vector(
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[DirectMissingMethodProblem]("sbt.Exit.apply"),
exclude[DirectMissingMethodProblem]("sbt.Reboot.apply"),
exclude[DirectMissingMethodProblem]("sbt.TemplateResolverInfo.apply"),
Dropped deprecated "compat" commands & strings Fixes #4089
2018-04-26 15:03:35 +02:00
// dropped private[sbt] method
exclude[DirectMissingMethodProblem]("sbt.BasicCommands.compatCommands"),
// dropped mainly internal command strings holder
exclude[MissingClassProblem]("sbt.BasicCommandStrings$Compat$"),
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
exclude[DirectMissingMethodProblem]("sbt.BasicCommands.rebootOptionParser"),
JSON port file This implements JSON-based port file. Thoughout the lifetime of the sbt server there will be `cwd / "project" / "target" / "active.json"`, which contains `url` field. Using this `url` the potential client, such as IDEs can find out which port number to hit. Ref #3508
2017-09-18 01:08:45 +02:00
// Changed the signature of Server method. nacho cheese.
implement tokenfile authentication
2017-09-22 05:05:48 +02:00
exclude[DirectMissingMethodProblem]("sbt.internal.server.Server.*"),
// Added method to ServerInstance. This is also internal.
exclude[ReversedMissingMethodProblem]("sbt.internal.server.ServerInstance.*"),
Filtering out mima issues
2017-10-02 21:52:02 +02:00
// Added method to CommandChannel. internal.
exclude[ReversedMissingMethodProblem]("sbt.internal.CommandChannel.*"),
Adds "reboot dev" This adds a new option `dev` to the `reboot` command, which deletes the only the current sbt artifacts from the boot directory. `reboot dev` reads actively from `build.properties` instead of using the current state since `reboot` can restart into another sbt version. In general, `reboot dev` is intended for the local development of sbt. Fixes #3590
2017-10-21 08:27:40 +02:00
// Added an overload to reboot. The overload is private[sbt].
exclude[ReversedMissingMethodProblem]("sbt.StateOps.reboot"),
Use ipcsocket
2018-01-30 06:43:30 +01:00
// Replace nailgun socket stuff
exclude[MissingClassProblem]("sbt.internal.NG*"),
exclude[MissingClassProblem]("sbt.internal.ReferenceCountedFileDescriptor"),
Make Watched use State#handleError
2018-03-12 18:13:17 +01:00
// made private[sbt] method private[this]
exclude[DirectMissingMethodProblem]("sbt.State.handleException"),
Upgrade to contraband 0.4.0
2018-03-12 16:18:42 +01:00
// copy method was never meant to be public
exclude[DirectMissingMethodProblem]("sbt.CommandSource.copy"),
exclude[DirectMissingMethodProblem]("sbt.CommandSource.copy$default$*"),
exclude[DirectMissingMethodProblem]("sbt.Exec.copy"),
exclude[DirectMissingMethodProblem]("sbt.Exec.copy$default$*"),
Fix mima issue
2018-06-26 04:34:55 +02:00
// internal
exclude[ReversedMissingMethodProblem]("sbt.internal.client.ServerConnection.*"),
Add Mima filters for sbt.internal
2020-05-22 14:39:45 +02:00
exclude[MissingTypesProblem]("sbt.internal.server.ServerConnection*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.server.ServerConnection.*")
IPC Unix domain socket for sbt server In addition to TCP, this adds sbt server support for IPC (interprocess communication) using Unix domain socket and Windows named pipe. The use of Unix domain socket has performance and security benefits.
2017-11-28 03:37:31 +01:00
),
unmanagedSources in (Compile, headerCreate) := {
val old = (unmanagedSources in (Compile, headerCreate)).value
format build.sbt
2019-05-11 09:42:06 +02:00
old filterNot { x =>
(x.getName startsWith "NG") || (x.getName == "ReferenceCountedFileDescriptor.java")
}
IPC Unix domain socket for sbt server In addition to TCP, this adds sbt server support for IPC (interprocess communication) using Unix domain socket and Windows named pipe. The use of Unix domain socket has performance and security benefits.
2017-11-28 03:37:31 +01:00
},
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Format the build
2017-06-23 18:58:00 +02:00
.configure(
addSbtIO,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
addSbtCompilerInterface,
Format the build
2017-06-23 18:58:00 +02:00
addSbtCompilerClasspath,
Add global file repository task Every time that the compile task is run, there are potentially a large number of iops that must occur in order for sbt to generate the source file list as well as for zinc to check which files have changed since the last build. This can lead to a noticeable delay between when a build is started (either manually or by triggered execution) and when compilation actually begins. To reduce this latency, I am adding a global view of the file system that will be stored in BasicKeys.globalFileTreeView. To make this work, I introduce the StampedFile trait, which augments the java.io.File class with a stamp method that returns the zinc stamp for the file. For source files, this will be a hash of the file, while for binaries, it is just the last modified time. In order to gain access to the sbt.internal.inc.Stamper class, I had to append addSbtZinc to the commandProj configurations. This view may or may not use an in-memory cache of the file system tree to return the results. Because there is always the risk of the cache getting out of sync with the actual file system, I both make it optional to use a cache and provide a mechanism for flushing the cache. Moreover, the in-memory cache implementation in sbt.io, which is backed by a swoval FileTreeRepository, has the property that touching a monitored directory invalidates the entire directory within the cache, so the flush command isn't even strictly needed in general. Because caching is optional, the global is of a FileTreeDataView, which doesn't specify a caching strategy. Subsequent commits will make use of this to potentially speed up incremental compilation by caching the Stamps of the source files so that zinc does not need to compute the hashes itself and will allow for continuous builds to use the cache to monitor events instead of creating a new, standalone FileEventMonitor.
2018-08-26 01:43:48 +02:00
addSbtLmCore,
addSbtZinc
Format the build
2017-06-23 18:58:00 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Move `util-appmacro` to sbt as `core-macros` This commit moves everything behind the old util-appmacro over to sbt/sbt. appmacro has been renamed as core-macros. It is indeed the project that defines the main logic to manipulate macros, and defines interfaces that are then implemented by main-settings. Because of this strong relationship between these two modules, I find that they have to stay together and be able to be modified in one commit. I've realised this while hacking on the macro changes for the usability of sbt. The reason for this change is because the logic of this module is really tight to the implementation of sbt and, I would even say, essentially define the sbt DSL.
2017-05-23 23:48:20 +02:00
// The core macro project defines the main logic of the DSL, abstracted
Fix typo
2019-07-28 05:49:24 +02:00
// away from several sbt implementors (tasks, settings, et cetera).
Reformat all util-appmacro
2017-05-23 23:53:04 +02:00
lazy val coreMacrosProj = (project in file("core-macros"))
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
.dependsOn(collectionProj)
Reformat all util-appmacro
2017-05-23 23:53:04 +02:00
.settings(
Use a macro to create StringTypeTag instances Using the scala reflect library always introduces significant classloading overhead. We can eliminate the classloading overhead by generating StringTypeTags at compile time instead. This sped up average project loading time by a few hundred milliseconds on my computer. The ManagedLoggedReporter in zinc is still using the type tag based apis but after the next sbt release, we can upgrade the zinc apis. We also could consider breaking binary compatibility.
2020-07-29 23:55:19 +02:00
baseSettings :+ (crossScalaVersions := (scala212 :: scala213 :: Nil)),
Move `util-appmacro` to sbt as `core-macros` This commit moves everything behind the old util-appmacro over to sbt/sbt. appmacro has been renamed as core-macros. It is indeed the project that defines the main logic to manipulate macros, and defines interfaces that are then implemented by main-settings. Because of this strong relationship between these two modules, I find that they have to stay together and be able to be modified in one commit. I've realised this while hacking on the macro changes for the usability of sbt. The reason for this change is because the logic of this module is really tight to the implementation of sbt and, I would even say, essentially define the sbt DSL.
2017-05-23 23:48:20 +02:00
name := "Core Macros",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
libraryDependencies += "org.scala-lang" % "scala-compiler" % scalaVersion.value,
Add exportPipelining setting to implement subproject opt-out Fixes https://github.com/sbt/sbt/issues/5762 Fixes https://github.com/sbt/sbt/issues/5754 Ref https://github.com/sbt/zinc/pull/883
2020-08-16 19:57:10 +02:00
SettingKey[Boolean]("exportPipelining") := false,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
Move `util-appmacro` to sbt as `core-macros` This commit moves everything behind the old util-appmacro over to sbt/sbt. appmacro has been renamed as core-macros. It is indeed the project that defines the main logic to manipulate macros, and defines interfaces that are then implemented by main-settings. Because of this strong relationship between these two modules, I find that they have to stay together and be able to be modified in one commit. I've realised this while hacking on the macro changes for the usability of sbt. The reason for this change is because the logic of this module is really tight to the implementation of sbt and, I would even say, essentially define the sbt DSL.
2017-05-23 23:48:20 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Fixes scope=Scope for Setting (core defined in collectionProj) to define the settings system used in build definitions
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val mainSettingsProj = (project in file("main-settings"))
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
.dependsOn(
completeProj,
commandProj,
stdTaskProj,
coreMacrosProj,
utilLogging,
utilCache,
utilRelation,
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
Tell neg test suite the classpath via sbt
2017-05-24 10:27:51 +02:00
name := "Main Settings",
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
testOptions in Test ++= {
val cp = (Test / fullClasspathAsJars).value.map(_.data).mkString(java.io.File.pathSeparator)
val framework = TestFrameworks.ScalaTest
Tests.Argument(framework, s"-Dsbt.server.classpath=$cp") ::
Tests.Argument(framework, s"-Dsbt.server.version=${version.value}") ::
Tests.Argument(framework, s"-Dsbt.server.scala.version=${scalaVersion.value}") :: Nil
},
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
mimaBinaryIssueFilters ++= Seq(
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.Previous#References.getReferences"),
exclude[IncompatibleSignatureProblem]("sbt.Def.delegate"),
exclude[IncompatibleSignatureProblem]("sbt.Def.add"),
exclude[IncompatibleSignatureProblem]("sbt.Def.grouped"),
exclude[IncompatibleSignatureProblem]("sbt.Def.compile"),
exclude[IncompatibleSignatureProblem]("sbt.Def.asTransform"),
exclude[DirectMissingMethodProblem]("sbt.Def.StaticScopes"),
exclude[IncompatibleSignatureProblem]("sbt.Previous.this"),
exclude[DirectMissingMethodProblem]("sbt.BuildRef.apply"),
exclude[DirectMissingMethodProblem]("sbt.ScopeMask.apply"),
exclude[DirectMissingMethodProblem]("sbt.Def.intersect"),
exclude[DirectMissingMethodProblem]("sbt.LocalProject.apply"),
exclude[DirectMissingMethodProblem]("sbt.std.InitializeInstance.pure"),
exclude[DirectMissingMethodProblem]("sbt.std.InitializeInstance.flatten"),
exclude[DirectMissingMethodProblem]("sbt.std.InitializeInstance.map"),
exclude[DirectMissingMethodProblem]("sbt.std.InitializeInstance.app"),
exclude[DirectMissingMethodProblem]("sbt.std.ParserInstance.pure"),
exclude[DirectMissingMethodProblem]("sbt.std.ParserInstance.map"),
exclude[DirectMissingMethodProblem]("sbt.std.ParserInstance.app"),
exclude[DirectMissingMethodProblem]("sbt.std.ParserInstance.pure"),
exclude[DirectMissingMethodProblem]("sbt.std.TaskInstance.pure"),
exclude[DirectMissingMethodProblem]("sbt.std.TaskInstance.flatten"),
exclude[DirectMissingMethodProblem]("sbt.std.TaskInstance.map"),
exclude[DirectMissingMethodProblem]("sbt.std.TaskInstance.app"),
exclude[DirectMissingMethodProblem]("sbt.std.FullInstance.flatten"),
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
exclude[DirectMissingMethodProblem]("sbt.Scope.display012StyleMasked"),
Give Scoped a default equals/hashCode implementation
2018-03-27 02:36:41 +02:00
// added a method to a sealed trait
exclude[InheritedNewAbstractMethodProblem]("sbt.Scoped.canEqual"),
exclude[InheritedNewAbstractMethodProblem]("sbt.ScopedTaskable.canEqual"),
Extract Taskable from ScopedTaskable
2020-02-16 20:51:53 +01:00
// widened ScopedTaskable parameter to (new) supertype Taskable
exclude[IncompatibleSignatureProblem]("sbt.Scoped#RichTaskable*.this"),
exclude[IncompatibleSignatureProblem]("sbt.TupleSyntax.t*ToTable*"),
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
.configure(
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
addSbtIO,
addSbtCompilerInterface,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
addSbtCompilerClasspath,
Adapt to new library management API
2017-07-16 00:09:40 +02:00
addSbtLmCore
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
lazy val zincLmIntegrationProj = (project in file("zinc-lm-integration"))
.settings(
name := "Zinc LM Integration",
testedBaseSettings,
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
testOptions in Test +=
Tests.Argument(TestFrameworks.ScalaTest, s"-Dsbt.zinc.version=$zincVersion"),
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
mimaSettingsSince(sbt13Plus),
Mima
2020-04-24 23:43:07 +02:00
mimaBinaryIssueFilters ++= Seq(
exclude[IncompatibleMethTypeProblem]("sbt.internal.inc.ZincComponentCompiler*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.inc.ZincComponentCompiler*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.inc.ZincLMHelper.update"),
),
Add launcher interface dependency Previously the zincLmIntegrationProj would compile if the meta build classpath leaked into the compilation classpath. I found that the project would not compile a clean build running an sbt built off of origin/develop.
2019-05-09 03:26:15 +02:00
libraryDependencies += launcherInterface,
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
)
.configure(addSbtZincCompileCore, addSbtLmCore, addSbtLmIvyTest)
Cleanup Dependencies
2016-11-23 16:17:34 +01:00
// The main integration project for sbt. It brings all of the projects together, configures them, and provides for overriding conventions.
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val mainProj = (project in file("main"))
sbt-scalafmt 1.3
2017-06-16 22:11:33 +02:00
.enablePlugins(ContrabandPlugin)
format build.sbt
2019-05-11 09:42:06 +02:00
.dependsOn(
logicProj,
actionsProj,
mainSettingsProj,
runProj,
commandProj,
collectionProj,
scriptedPluginProj,
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
zincLmIntegrationProj,
utilLogging,
format build.sbt
2019-05-11 09:42:06 +02:00
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
Make use of the nicer Project settings syntax in 0.13.8.
2015-03-27 00:22:24 +01:00
testedBaseSettings,
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
name := "Main",
check PluginCross.scala consisntency
2018-10-05 19:32:40 +02:00
checkPluginCross := {
val sv = scalaVersion.value
build: Cleanup Dependencies
2020-01-10 14:41:55 +01:00
val f = baseDirectory.value / "src" / "main" / "scala" / "sbt" / "PluginCross.scala"
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
if (sv.startsWith("2.12") && !IO.readLines(f).exists(_.contains(s""""$sv""""))) {
build: Cleanup Dependencies
2020-01-10 14:41:55 +01:00
sys.error(s"PluginCross.scala does not match up with the scalaVersion $sv")
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
}
Coursier dependency resolution integration This adds dependency to LM implemented using Coursier. I had to copy paste a bunch of code from sbt-coursier-shared to break the dependency to sbt. `Global / useCoursier := false` or `-Dsbt.coursier=false` be used to opt-out of using Coursier for the dependency resolution.
2019-03-09 02:15:04 +01:00
},
build: Cleanup Dependencies
2020-01-10 14:41:55 +01:00
libraryDependencies ++=
Use java caffeine library rather than scalacache sbt depends on scalacache (which hasn't been updated in about a year) and we really don't need the functionality provided by scalacache. In fact, the java api is somewhat easier to work with for our use case. The motivation is that scalacache uses slf4j for logging which meant that it was implicitly loading log4j. This caused some noisy logs during shutdown when the previously unused cache was initialized just to be cleaned up. This commit also upgrades caffeine and moving forward we can always upgrade caffeine (and potentially shade it) without any conflict with the scalacache version.
2020-08-07 21:49:39 +02:00
(Seq(scalaXml, launcherInterface, caffeine, lmCoursierShaded) ++ log4jModules),
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
libraryDependencies ++= (scalaVersion.value match {
case v if v.startsWith("2.12.") => List()
case _ => List(scalaPar)
}),
migrate PluginTrigger and ProjectOrigin to Contraband (#3191) and move TestFramework to a non case class.
2017-05-13 14:01:51 +02:00
managedSourceDirectories in Compile +=
baseDirectory.value / "src" / "main" / "contraband-scala",
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
sourceManaged in (Compile, generateContrabands) := baseDirectory.value / "src" / "main" / "contraband-scala",
run 10000 examples to reduce flakiness
2019-05-11 09:41:41 +02:00
testOptions in Test += Tests
reduce the example size to 1000
2019-05-11 10:52:42 +02:00
.Argument(TestFrameworks.ScalaCheck, "-minSuccessfulTests", "1000"),
Add exportPipelining setting to implement subproject opt-out Fixes https://github.com/sbt/sbt/issues/5762 Fixes https://github.com/sbt/sbt/issues/5754 Ref https://github.com/sbt/zinc/pull/883
2020-08-16 19:57:10 +02:00
SettingKey[Boolean]("usePipelining") := false,
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
implement tokenfile authentication
2017-09-22 05:05:48 +02:00
mimaBinaryIssueFilters ++= Vector(
Unified slash syntax Fixes sbt/sbt#1812 This adds unified slash syntax for both sbt shell and the build.sbt DSL. Instead of the current `<project-id>/config:intask::key`, this adds `<project-id>/<config-ident>/intask/key` where <config-ident> is the Scala identifier notation for the configurations like `Compile` and `Test`. This also adds a series of implicits called `SlashSyntax` that adds `/` operators to project refererences, configuration, and keys such that the same syntax works in build.sbt. These examples work for both from the shell and in build.sbt. Global / cancelable ThisBuild / scalaVersion Test / test root / Compile / compile / scalacOptions ProjectRef(uri("file:/xxx/helloworld/"),"root")/Compile/scalacOptions Zero / Zero / name The inspect command now outputs something that can be copy-pasted: > inspect compile [info] Task: sbt.inc.Analysis [info] Description: [info] Compiles sources. [info] Provided by: [info] ProjectRef(uri("file:/xxx/helloworld/"),"root")/Compile/compile [info] Defined at: [info] (sbt.Defaults) Defaults.scala:326 [info] Dependencies: [info] Compile/manipulateBytecode [info] Compile/incCompileSetup [info] Reverse dependencies: [info] Compile/printWarnings [info] Compile/products [info] Compile/discoveredSbtPlugins [info] Compile/discoveredMainClasses [info] Delegates: [info] Compile/compile [info] compile [info] ThisBuild/Compile/compile [info] ThisBuild/compile [info] Zero/Compile/compile [info] Global/compile [info] Related: [info] Test/compile
2017-09-27 08:21:56 +02:00
// New and changed methods on KeyIndex. internal.
exclude[ReversedMissingMethodProblem]("sbt.internal.KeyIndex.*"),
add Mima exclusion
2019-01-04 15:55:28 +01:00
// internal
evict some mima errors in sbt.internal
2020-05-12 17:34:34 +02:00
exclude[IncompatibleMethTypeProblem]("sbt.internal.*"),
Remove all warnings from mainProj
2017-12-14 14:41:40 +01:00
// Changed signature or removed private[sbt] methods
exclude[DirectMissingMethodProblem]("sbt.Classpaths.unmanagedLibs0"),
exclude[DirectMissingMethodProblem]("sbt.Defaults.allTestGroupsTask"),
exclude[DirectMissingMethodProblem]("sbt.Plugins.topologicalSort"),
exclude[IncompatibleMethTypeProblem]("sbt.Defaults.allTestGroupsTask"),
Add the ability to resurrect closed classloaders There have been a number of complaints about the new classloader closing behavior. It is too aggressive about closing classloaders after test and run. This commit softens the behavior by allowing a classloader to be resurrected after close by creating a new zombie classloader that has the same urls as the original classloader. After this commit, we always close the classloaders when we are done, but they can still leak file descriptors if a zombie is created. To configure the behavior, I add the allowZombieClassLoaders key. If it is false (which is default), we will warn but still allow them. If it is true, then we silence the warning. In a later version of sbt, we can change the semantics to be strict. I verified after this change that I could add a shutdown hook in `run` and it would be evaluated so long as I set `bgCopyClasspath := false`. Otherwise the needed jars were deleted before the hooks could run. Bonus: delete unused ResourceLoaderImpl class
2019-09-13 19:49:09 +02:00
exclude[DirectMissingMethodProblem]("sbt.StandardMain.shutdownHook"),
Remove custom ExternalHooks This is now handled by passing a custom instance of ReadStamps to CompileOptions instead.
2020-05-01 05:32:40 +02:00
exclude[DirectMissingMethodProblem]("sbt.nio.Keys.compileBinaryFileInputs"),
exclude[DirectMissingMethodProblem]("sbt.nio.Keys.compileSourceFileInputs"),
Add the ability to resurrect closed classloaders There have been a number of complaints about the new classloader closing behavior. It is too aggressive about closing classloaders after test and run. This commit softens the behavior by allowing a classloader to be resurrected after close by creating a new zombie classloader that has the same urls as the original classloader. After this commit, we always close the classloaders when we are done, but they can still leak file descriptors if a zombie is created. To configure the behavior, I add the allowZombieClassLoaders key. If it is false (which is default), we will warn but still allow them. If it is true, then we silence the warning. In a later version of sbt, we can change the semantics to be strict. I verified after this change that I could add a shutdown hook in `run` and it would be evaluated so long as I set `bgCopyClasspath := false`. Otherwise the needed jars were deleted before the hooks could run. Bonus: delete unused ResourceLoaderImpl class
2019-09-13 19:49:09 +02:00
exclude[MissingClassProblem]("sbt.internal.ResourceLoaderImpl"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.internal.ConfigIndex.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.Inspect.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.ProjectIndex.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.BuildIndex.*"),
replace LSP compiler reporter by BSP one
2020-05-01 13:41:13 +02:00
exclude[IncompatibleSignatureProblem]("sbt.internal.server.BuildServerReporter.*"),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[VirtualStaticMemberProblem]("sbt.internal.server.LanguageServerProtocol.*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.librarymanagement.IvyXml.*"),
Add explicit return type to plugin settings
2019-10-19 10:38:54 +02:00
exclude[IncompatibleSignatureProblem]("sbt.ScriptedPlugin.*Settings"),
exclude[IncompatibleSignatureProblem]("sbt.plugins.SbtPlugin.*Settings"),
Make all test and run classloaders parallel capable A number of users were reporting issues with deadlocking when using 1.3.2: https://github.com/sbt/sbt/issues/5116. This seems to be because most of the sbt created classloaders were not actually parallel capable. In order for a classloader to be registered as a parallel capable, ALL of the parent classes except for object in the class hierarchy must be registered as a parallel capable: https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable--. If a classloader is not registered as parallel capable, then a global lock will be used internally for classloading and this can lead to deadlock. It is impossible to register a scala 2 classloader as parallel capable so I ported all of the classloaders to java. This commit updates the java-serialization scripted test. Prior to the port, the new version of the test would more or less always deadlock. After this change, I haven't been able to reproduce a deadlock. This had no significant performance impact when I reran https://github.com/eatkins/scala-build-watch-performance
2019-09-27 19:25:48 +02:00
// Removed private internal classes
exclude[MissingClassProblem]("sbt.internal.ReverseLookupClassLoaderHolder$BottomClassLoader"),
Run scalafmtSbt Also add scalafmtSbtCheck to travis.
2019-11-30 23:18:41 +01:00
exclude[MissingClassProblem](
"sbt.internal.ReverseLookupClassLoaderHolder$ReverseLookupClassLoader$ResourceLoader"
),
Make all test and run classloaders parallel capable A number of users were reporting issues with deadlocking when using 1.3.2: https://github.com/sbt/sbt/issues/5116. This seems to be because most of the sbt created classloaders were not actually parallel capable. In order for a classloader to be registered as a parallel capable, ALL of the parent classes except for object in the class hierarchy must be registered as a parallel capable: https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable--. If a classloader is not registered as parallel capable, then a global lock will be used internally for classloading and this can lead to deadlock. It is impossible to register a scala 2 classloader as parallel capable so I ported all of the classloaders to java. This commit updates the java-serialization scripted test. Prior to the port, the new version of the test would more or less always deadlock. After this change, I haven't been able to reproduce a deadlock. This had no significant performance impact when I reran https://github.com/eatkins/scala-build-watch-performance
2019-09-27 19:25:48 +02:00
exclude[MissingClassProblem]("sbt.internal.ReverseLookupClassLoaderHolder$ClassLoadingLock"),
Run scalafmtSbt Also add scalafmtSbtCheck to travis.
2019-11-30 23:18:41 +01:00
exclude[MissingClassProblem](
"sbt.internal.ReverseLookupClassLoaderHolder$ReverseLookupClassLoader"
),
Make all test and run classloaders parallel capable A number of users were reporting issues with deadlocking when using 1.3.2: https://github.com/sbt/sbt/issues/5116. This seems to be because most of the sbt created classloaders were not actually parallel capable. In order for a classloader to be registered as a parallel capable, ALL of the parent classes except for object in the class hierarchy must be registered as a parallel capable: https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable--. If a classloader is not registered as parallel capable, then a global lock will be used internally for classloading and this can lead to deadlock. It is impossible to register a scala 2 classloader as parallel capable so I ported all of the classloaders to java. This commit updates the java-serialization scripted test. Prior to the port, the new version of the test would more or less always deadlock. After this change, I haven't been able to reproduce a deadlock. This had no significant performance impact when I reran https://github.com/eatkins/scala-build-watch-performance
2019-09-27 19:25:48 +02:00
exclude[MissingClassProblem]("sbt.internal.LayeredClassLoaderImpl"),
Remove FileManagement This was unused.
2020-05-05 23:39:22 +02:00
exclude[MissingClassProblem]("sbt.internal.FileManagement"),
exclude[MissingClassProblem]("sbt.internal.FileManagement$"),
exclude[MissingClassProblem]("sbt.internal.FileManagement$CopiedFileTreeRepository"),
Add Mima filters for sbt.internal
2020-05-22 14:39:45 +02:00
exclude[MissingClassProblem]("sbt.internal.server.LanguageServerReporter*"),
Remove custom ExternalHooks This is now handled by passing a custom instance of ReadStamps to CompileOptions instead.
2020-05-01 05:32:40 +02:00
exclude[MissingClassProblem]("sbt.internal.ExternalHooks"),
exclude[MissingClassProblem]("sbt.internal.ExternalHooks$"),
Fix MiMa
2019-10-17 23:27:43 +02:00
// false positives
exclude[DirectMissingMethodProblem]("sbt.plugins.IvyPlugin.requires"),
exclude[DirectMissingMethodProblem]("sbt.plugins.JUnitXmlReportPlugin.requires"),
exclude[DirectMissingMethodProblem]("sbt.plugins.Giter8TemplatePlugin.requires"),
exclude[DirectMissingMethodProblem]("sbt.plugins.JvmPlugin.requires"),
exclude[DirectMissingMethodProblem]("sbt.plugins.SbtPlugin.requires"),
exclude[DirectMissingMethodProblem]("sbt.ResolvedClasspathDependency.apply"),
exclude[DirectMissingMethodProblem]("sbt.ClasspathDependency.apply"),
Fix MiMa
2019-10-18 19:39:39 +02:00
exclude[IncompatibleSignatureProblem]("sbt.plugins.SemanticdbPlugin.globalSettings"),
Fix MiMa
2019-10-17 23:27:43 +02:00
// File -> Source
exclude[DirectMissingMethodProblem]("sbt.Defaults.cleanFilesTask"),
exclude[IncompatibleSignatureProblem]("sbt.Defaults.resourceConfigPaths"),
exclude[IncompatibleSignatureProblem]("sbt.Defaults.sourceConfigPaths"),
exclude[IncompatibleSignatureProblem]("sbt.Defaults.configPaths"),
exclude[IncompatibleSignatureProblem]("sbt.Defaults.paths"),
exclude[IncompatibleSignatureProblem]("sbt.Keys.csrPublications"),
Run scalafmtSbt Also add scalafmtSbtCheck to travis.
2019-11-30 23:18:41 +01:00
exclude[IncompatibleSignatureProblem](
"sbt.coursierint.CoursierArtifactsTasks.coursierPublicationsTask"
),
exclude[IncompatibleSignatureProblem](
"sbt.coursierint.CoursierArtifactsTasks.coursierPublicationsTask"
),
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.coursierint.LMCoursier.coursierConfiguration"),
exclude[IncompatibleSignatureProblem]("sbt.coursierint.LMCoursier.publicationsSetting"),
exclude[IncompatibleSignatureProblem]("sbt.Project.inThisBuild"),
exclude[IncompatibleSignatureProblem]("sbt.Project.inConfig"),
exclude[IncompatibleSignatureProblem]("sbt.Project.inTask"),
exclude[IncompatibleSignatureProblem]("sbt.Project.inScope"),
exclude[IncompatibleSignatureProblem]("sbt.ProjectExtra.inThisBuild"),
exclude[IncompatibleSignatureProblem]("sbt.ProjectExtra.inConfig"),
exclude[IncompatibleSignatureProblem]("sbt.ProjectExtra.inTask"),
exclude[IncompatibleSignatureProblem]("sbt.ProjectExtra.inScope"),
addPluginSbtFile command fixes Ref #4211 Fixes #4395 Fixes #4600 This is a reimplementation of `--addPluginSbtFile`. #4211 implemented the command to load extra `*.sbt` files as part of the global plugin subproject. That had the unwanted side effects of not working when `.sbt/1.0/plugins` directory does not exist. This changes the strategy to load the `*.sbt` files as part of the meta build. ``` $ sbt -Dsbt.global.base=/tmp/hello/global --addPluginSbtFile=/tmp/plugins/plugin.sbt [info] Loading settings for project hello-build from plugin.sbt ... [info] Loading project definition from /private/tmp/hello/project sbt:hello> plugins In file:/private/tmp/hello/ sbt.plugins.IvyPlugin: enabled in root sbt.plugins.JvmPlugin: enabled in root sbt.plugins.CorePlugin: enabled in root sbt.ScriptedPlugin sbt.plugins.SbtPlugin sbt.plugins.SemanticdbPlugin: enabled in root sbt.plugins.JUnitXmlReportPlugin: enabled in root sbt.plugins.Giter8TemplatePlugin: enabled in root sbtvimquit.VimquitPlugin: enabled in root ```
2019-11-10 09:01:28 +01:00
exclude[MissingTypesProblem]("sbt.internal.Load*"),
exclude[IncompatibleSignatureProblem]("sbt.internal.Load*"),
Add Mima filters for sbt.internal
2020-05-22 14:39:45 +02:00
exclude[MissingTypesProblem]("sbt.internal.server.NetworkChannel"),
Give a more precise type to mkIvyConfiguration This makes it possible to do mkIvyConfiguration.value.withXXX(...) for all the methods in InlineIvyConfiguration. (I need this to remove inter-project resolvers when fetching dotty from sbt-dotty to avoid accidentally fetching a local project in the build of dotty itself).
2019-12-05 17:45:33 +01:00
// IvyConfiguration was replaced by InlineIvyConfiguration in the generic
// signature, this does not break compatibility regardless of what
// cast a compiler might have inserted based on the old signature
// since we're returning the same values as before.
Mima
2020-04-24 23:43:07 +02:00
exclude[IncompatibleSignatureProblem]("sbt.Classpaths.mkIvyConfiguration"),
exclude[IncompatibleMethTypeProblem]("sbt.internal.server.Definition*"),
Remove HTTP support without explicit opt-in Ref https://github.com/sbt/sbt/issues/4905
2020-06-07 05:01:39 +02:00
exclude[IncompatibleTemplateDefProblem]("sbt.internal.server.LanguageServerProtocol"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.warnInsecureProtocol"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.warnInsecureProtocolInModules"),
Zinc 1.4.0-M6
2020-06-14 21:55:37 +02:00
exclude[MissingClassProblem]("sbt.internal.ExternalHooks*"),
Add multi-client ui to server This commit makes it possible for the sbt server to render the same ui to multiple clients. The network client ui should look nearly identical to the console ui except for the log messages about the experimental client. The way that it works is that it associates a ui thread with each terminal. Whenever a command starts or completes, callbacks are invoked on the various channels to update their ui state. For example, if there are two clients and one of them runs compile, then the prompt is changed from AskUser to Running for the terminal that initiated the command while the other client remains in the AskUser state. Whenever the client changes uses ui states, the existing thread is terminated if it is running and a new thread is begun. The UITask formalizes this process. It is based on the AskUser class from older versions of sbt. In fact, there is an AskUserTask which is very similar. It uses jline to read input from the terminal (which could be a network terminal). When it gets a line, it submits it to the CommandExchange and exits. Once the next command is run (which may or may not be the command it submitted), the ui state will be reset. The debug, info, warn and error commands should work with the multi client ui. When run, they set the log level globally, not just for the client that set the level.
2019-12-18 19:24:32 +01:00
// This seems to be a mima problem. The older constructor still exists but
// mima seems to incorrectly miss the secondary constructor that provides
// the binary compatible version.
exclude[IncompatibleMethTypeProblem]("sbt.internal.server.NetworkChannel.this"),
Refactor watch The existing implementation of watch did not work with the thin client. In sbt 1.3.0, watch was changed to be a blocking command that performed manual task evaluation. This commit makes the implementation more similar to < 1.3.0 where watch modifies the state and after running the user specified command(s), it enters a blocking command. The new blocking command is very similar to the shell command. As part of this change, I also reworked some of the internals of watch so that a number of threads are spawned for reading file and input events. By using background threads that write to a single event queue, we are able to block on the file events and terminal input stream rather than polling. After this change, the cpu utilization as measured by ps drops from roughly 2% of a cpu to 0. To integrate with the network client, we introduce a new UITask that is similar to the AskUserTask but instead of reading lines and adding execs to the command queue, it reads characters and converts them into watch commands that we also append to the command queue. With this new implementation, the watch task that was added in 1.3.0 no longer works. My guess is that no one was really using it. It wasn't documented anywhere. The motivation for the task implementation was that it could be called within another task which would let users define a task that monitors for file changes before running. Since this had never been advertised and is only of limited utility anyway, I think it's fine to break it. I also had to disable the input-parser and symlinks tests. I'm not 100% sure why the symlinks test was failing. It would tend to work on my machine but fail in CI. I gave up on debugging it. The input-parser test also fails but would be a good candidate to be moved to the client test in the serverTestProj. At any rate, it was testing a code path that was only exercised if the user changed the watchInputStream method which is highly unlikely to have been done in any user builds. The WatchSpec had become a nuisance and wasn't really preventing from any regressions so I removed it. The scripted tests are how we test watch.
2020-06-22 02:10:20 +02:00
exclude[IncompatibleSignatureProblem]("sbt.internal.DeprecatedContinuous.taskDefinitions"),
Build pipelining Ref https://github.com/sbt/zinc/pull/744 This implements `ThisBuild / usePipelining`, which configures subproject pipelining available from Zinc 1.4.0. The basic idea is to start subproject compilation as soon as pickle JARs (early output) becomes available. This is in part enabled by Scala compiler's new flags `-Ypickle-java` and `-Ypickle-write`. The other part of magic is the use of `Def.promise`: ``` earlyOutputPing := Def.promise[Boolean], ``` This notifies `compileEarly` task, which to the rest of the tasks would look like a normal task but in fact it is promise-blocked. In other words, without calling full `compile` task together, `compileEarly` will never return, forever waiting for the `earlyOutputPing`.
2020-07-27 02:46:43 +02:00
exclude[MissingClassProblem]("sbt.internal.SettingsGraph*"),
// Tasks include non-Files, but it's ok
exclude[IncompatibleSignatureProblem]("sbt.Defaults.outputConfigPaths"),
// private[sbt]
exclude[DirectMissingMethodProblem]("sbt.Classpaths.trackedExportedProducts"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.trackedExportedJarProducts"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.unmanagedDependencies0"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.internalDependenciesImplTask"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.internalDependencyJarsImplTask"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.interDependencies"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.productsTask"),
exclude[DirectMissingMethodProblem]("sbt.Classpaths.jarProductsTask"),
Use java caffeine library rather than scalacache sbt depends on scalacache (which hasn't been updated in about a year) and we really don't need the functionality provided by scalacache. In fact, the java api is somewhat easier to work with for our use case. The motivation is that scalacache uses slf4j for logging which meant that it was implicitly loading log4j. This caused some noisy logs during shutdown when the previously unused cache was initialized just to be cleaned up. This commit also upgrades caffeine and moving forward we can always upgrade caffeine (and potentially shade it) without any conflict with the scalacache version.
2020-08-07 21:49:39 +02:00
exclude[DirectMissingMethodProblem]("sbt.StandardMain.cache"),
Add internal multi logger implementation Prior to these changes, sbt was leaking large amounts of memory via log4j appenders. sbt has an unusual use case for log4j because it creates many ephemeral loggers while also having a global logger that is supposed to work for the duration of the sbt session. There is a lot of shared global state in log4j and properly cleaning up the ephemeral task appenders would break global logging. This commit fixes the behavior by introducing an alternate logging implementation. Users can still use the old log4j logging implementation but it will be off by default. The internal implementation is very simple: it just blocks the current thread and writes to all of the appenders. Nevertheless, I found the performance to be roughly identical to that of log4j in my sample project. As an experiment, I did the appending on a thread pool and got a significant performance improvement but I'll defer that to a later PR since parallel io is harder to reason about. Background: I was testing sbt performance in https://github.com/jtjeferreira/sbt-multi-module-sample and noticed that performance rapidly degraded after I ran compile a few times. I took a heap dump and it became obvious that sbt was leaking console appenders. Further investigation revealed that all of the leaking appenders in the project were coming from task streams. This made me think that the fix would be to track what loggers were created during task evaluation and clear them out when task evaluation completed. That almost worked except that log4j has an internal append only data structure containing logger names. Since we create unique logger names for each run, that internal data structure grew without bound. It looked like this could be worked around by creating a new log4j Configuration (where that data structure was stored) but while creating new configurations with each task runs did fix the leak, it also broke global logging, which was using a different configuration. At this point, I decided to write an alternate implementation of the appender api where I could be sure that the appenders were cleaned up without breaking global logging. Implementation: I made ConsoleAppender a trait and made it no longer extends log4j AbstractAppender. To do this, I had to remove the one log4j specific method, append(LogEvent). ConsoleAppender now has a method toLog4J that, in most cases, will return a log4j Appender that is almost identical to the Appenders that we previously used. To manage the loggers created during task evaluation, I introduce a new class, LoggerContext. The LoggerContext determines which logging backend to use and keeps track of what appenders and loggers have been created. We can create a fresh LoggerContext before each task evaluation and clear it out, cleaning up all of its resources after task evaluation concludes. In order to make this work, there were many places where we need to either pass in a LoggerContext or create a new one. The main magic is happening in the `next(State)` method in Main. This is where we create a new LoggerContext prior to command evaluation and clean it up after the evaluation completes. Users can toggle log4j using the new useLog4J key. They also can set the system property, sbt.log.uselog4j. The global logger will use the sbt internal implementation unless the system property is set. There are a fairly significant number of mima issues since I changed the type of ConsoleAppender. All of the mima changes were in the sbt.internal package so I think this should be ok. Effects: the memory leaks are gone. I successfully ran 5000 no-op compiles in the sbt-multi-module-sample above with no degradation of performace. There was a noticeable degradation after 30 no-op compiles before. During the refactor, I had to work on TestLogger and in doing so I also fixed https://github.com/sbt/sbt/issues/4480. This also should fix https://github.com/sbt/sbt/issues/4773
2020-08-05 20:23:35 +02:00
// internal logging apis,
exclude[IncompatibleSignatureProblem]("sbt.internal.LogManager*"),
exclude[MissingTypesProblem]("sbt.internal.RelayAppender"),
Port XMainConfiguration to Java The bytecode generated by 2.13 compiler contains scala.runtime.BoxedUnit in the constant pool. To avoid referencing scala-library, port XMainConfiguration to Java.
2021-01-10 20:16:35 +01:00
exclude[MissingClassProblem]("sbt.internal.TaskProgress$ProgressThread"),
// internal implementation
exclude[MissingClassProblem](
"sbt.internal.XMainConfiguration$ModifiedConfiguration$ModifiedAppProvider$ModifiedScalaProvider$"
),
implement tokenfile authentication
2017-09-22 05:05:48 +02:00
)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Format the build
2017-06-23 18:58:00 +02:00
.configure(
addSbtIO,
Adapt to new library management API
2017-07-16 00:09:40 +02:00
addSbtLmCore,
Fix librarymanagement project Id
2019-10-16 20:27:32 +02:00
addSbtLmIvy,
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
addSbtCompilerInterface,
Add back, re-configure & re-enable Scalafmt
2017-08-10 17:23:15 +02:00
addSbtZincCompile
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
// Strictly for bringing implicits and aliases from subsystems into the top-level sbt namespace through a single package object
// technically, we need a dependency on all of mainProj's dependencies, but we don't do that since this is strictly an integration project
// with the sole purpose of providing certain identifiers without qualification (with a package object)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
lazy val sbtProj = (project in file("sbt"))
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
.dependsOn(mainProj)
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
.settings(
start an instance of sbt in the background
2018-01-24 09:56:42 +01:00
testedBaseSettings,
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
name := "sbt",
Rewire to new modules
2015-09-14 09:27:22 +02:00
normalizedName := "sbt",
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
version := {
if (scalaVersion.value == baseScalaVersion) version.value
else version2_13.value
},
Use Scala 2.12.1 Bump up the Scala version used by sbt to 2.12.1. Most changes are migration of the integration tests.
2017-01-15 07:44:05 +01:00
crossScalaVersions := Seq(baseScalaVersion),
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
crossPaths := false,
Cross build to Scala 2.13
2021-01-11 01:23:43 +01:00
crossTarget := { target.value / scalaVersion.value },
Create RunFromSourceMain & "sbtOn" command
2017-11-23 15:58:26 +01:00
javaOptions ++= Seq("-Xdebug", "-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"),
Add, configure & enable MiMa
2017-07-20 18:31:39 +02:00
mimaSettings,
WatchSource = sbt.internal.io.Source Ref #3438
2017-08-28 06:42:26 +02:00
mimaBinaryIssueFilters ++= sbtIgnoredProblems,
Refactor server test This refactors the server test to reuse the server instance for the tests against the same build.
2019-10-21 02:42:52 +02:00
)
Fix sbt.IllegalReferenceSpec
2020-02-14 15:01:11 +01:00
.settings(
Test / run / connectInput := true,
Test / run / outputStrategy := Some(StdoutOutput),
Test / run / fork := true,
testOptions in Test ++= {
val cp = (Test / fullClasspathAsJars).value.map(_.data).mkString(java.io.File.pathSeparator)
val framework = TestFrameworks.ScalaTest
Tests.Argument(framework, s"-Dsbt.server.classpath=$cp") ::
Tests.Argument(framework, s"-Dsbt.server.version=${version.value}") ::
Tests.Argument(framework, s"-Dsbt.server.scala.version=${scalaVersion.value}") :: Nil
},
)
Refactor server test This refactors the server test to reuse the server instance for the tests against the same build.
2019-10-21 02:42:52 +02:00
.configure(addSbtIO, addSbtCompilerBridge)
lazy val serverTestProj = (project in file("server-test"))
Don't fork server tests I was seeing some failures in travis ci where the build crashed because it wasn't able to open a socket. This failure was happening in the scalatest fork runner so I decided to avoid forking entirely. An alternative approach would possibly be just to remove the scalatest framework from the server test project but not forking is nicer anyway.
2020-09-27 18:46:32 +02:00
.dependsOn(sbtProj % "compile->test", scriptedSbtReduxProj % "compile->test")
Refactor server test This refactors the server test to reuse the server instance for the tests against the same build.
2019-10-21 02:42:52 +02:00
.settings(
testedBaseSettings,
crossScalaVersions := Seq(baseScalaVersion),
publish / skip := true,
// make server tests serial
Disable supershell in server tests Also make test build files trigger in watch.
2020-06-22 00:46:18 +02:00
Test / watchTriggers += baseDirectory.value.toGlob / "src" / "server-test" / **,
Refactor server test This refactors the server test to reuse the server instance for the tests against the same build.
2019-10-21 02:42:52 +02:00
Test / parallelExecution := false,
Recover sbtOn
2018-03-26 16:37:25 +02:00
Test / run / connectInput := true,
Test / run / outputStrategy := Some(StdoutOutput),
Test / run / fork := true,
Don't fork server tests I was seeing some failures in travis ci where the build crashed because it wasn't able to open a socket. This failure was happening in the scalatest fork runner so I decided to avoid forking entirely. An alternative approach would possibly be just to remove the scalatest framework from the server test project but not forking is nicer anyway.
2020-09-27 18:46:32 +02:00
Test / sourceGenerators += Def.task {
val rawClasspath =
(Compile / fullClasspathAsJars).value.map(_.data).mkString(java.io.File.pathSeparator)
val cp =
if (scala.util.Properties.isWin) rawClasspath.replaceAllLiterally("\\", "\\\\")
else rawClasspath
val content = {
s"""|
|package testpkg
|
|object TestProperties {
| val classpath = "$cp"
| val version = "${version.value}"
| val scalaVersion = "${scalaVersion.value}"
|}
""".stripMargin
}
val file = (Test / target).value / "generated" / "src" / "test" / "scala" / "testpkg" / "TestProperties.scala"
IO.write(file, content)
file :: Nil
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
},
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Get rid of Fn1
2017-10-20 05:18:43 +02:00
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
val isWin = scala.util.Properties.isWin
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
val buildThinClient =
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
inputKey[JPath]("generate a java implementation of the thin client")
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
val thinClientClasspath =
taskKey[Seq[JPath]]("Generate the classpath for thin client (compacted for windows)")
val thinClientNativeImageCommand = taskKey[String]("The native image command")
val thinClientNativeImageOptions = settingKey[Seq[String]]("The native image options")
val thinClientNativeImageClass = settingKey[String]("The class for the native image")
val buildNativeThinClient = taskKey[JPath]("Generate a native executable")
// Use a TaskKey rather than SettingKey for nativeInstallDirectory so it can left unset by default
val nativeInstallDirectory = taskKey[JPath]("The install directory for the native executable")
val installNativeThinClient = inputKey[JPath]("Install the native executable")
val nativeThinClientPath = settingKey[JPath]("The location of the native executable")
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
lazy val sbtClientProj = (project in file("client"))
.dependsOn(commandProj)
.settings(
commonBaseSettings,
Build the thin client with scala 2.12.11 With scala 2.12.12, building the thin client fails aggressively. See https://github.com/sbt/sbt/issues/5756.
2020-08-15 18:38:41 +02:00
scalaVersion := "2.12.11", // The thin client does not build with 2.12.12
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
publish / skip := true,
name := "sbt-client",
mimaPreviousArtifacts := Set.empty,
crossPaths := false,
exportJars := true,
libraryDependencies += jansi,
libraryDependencies += scalatest % "test",
/*
* On windows, the raw classpath is too large to be a command argument to an
* external process so we create symbolic links with short names to get the
* classpath length under the limit.
*/
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
thinClientClasspath := {
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
val original = (Compile / fullClasspathAsJars).value.map(_.data)
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
val outputDir = target.value / "thinclientcp"
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
IO.createDirectory(outputDir)
Files.walk(outputDir.toPath).forEach {
case f if f.getFileName.toString.endsWith(".jar") => Files.deleteIfExists(f)
case _ =>
}
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
original.zipWithIndex.map {
case (f, i) => Files.createSymbolicLink(outputDir.toPath / s"$i.jar", f.toPath)
}
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
},
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
thinClientNativeImageCommand := System.getProperty("sbt.native-image", "native-image").toString,
Rename to sbtn
2020-08-14 04:56:02 +02:00
buildNativeThinClient / name := s"sbtn${if (isWin) ".exe" else ""}",
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
nativeThinClientPath := target.value.toPath / "bin" / (buildNativeThinClient / name).value,
thinClientNativeImageClass := "sbt.client.Client",
buildNativeThinClient := {
val hasChanges = thinClientClasspath.outputFileChanges.hasChanges
val cpString =
thinClientClasspath.value.map(_.getFileName).mkString(java.io.File.pathSeparator)
val prefix = Seq(thinClientNativeImageCommand.value, "-cp", cpString)
val full = prefix ++ thinClientNativeImageOptions.value :+ thinClientNativeImageClass.value
val dir = target.value
if (hasChanges || !Files.exists(nativeThinClientPath.value)) {
val pb = new java.lang.ProcessBuilder(full: _*)
pb.directory(dir / "thinclientcp")
val proc = pb.start()
val thread = new Thread {
setDaemon(true)
val is = proc.getInputStream
val es = proc.getErrorStream
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
override def run(): Unit = {
Thread.sleep(100)
while (proc.isAlive) {
if (is.available > 0 || es.available > 0) {
while (is.available > 0) System.out.print(is.read.toChar)
while (es.available > 0) System.err.print(es.read.toChar)
}
if (proc.isAlive) Thread.sleep(10)
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
}
}
}
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
thread.start()
proc.waitFor(5, java.util.concurrent.TimeUnit.MINUTES)
assert(proc.exitValue == 0, s"Exit value ${proc.exitValue} was nonzero")
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
}
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
nativeThinClientPath.value
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
},
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
thinClientNativeImageOptions := Seq(
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
"--no-fallback",
s"--initialize-at-run-time=sbt.client",
"--verbose",
"-H:IncludeResourceBundles=jline.console.completer.CandidateListCompletionHandler",
"-H:+ReportExceptionStackTraces",
Add flag to disable graal parsing of command args The graalvm was swallowing all -D arguments and adding them to the process system properties. This is undesirable since there are sbt commands that have arguments starting with '-D'. It also breaks our ability to pass system properties to the forked sbt process.
2020-07-01 23:29:50 +02:00
"-H:-ParseRuntimeOptions",
Rename to sbtn
2020-08-14 04:56:02 +02:00
s"-H:Name=${target.value / "bin" / "sbtn"}",
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
),
Add installNativeThinClient task This allows a user to install the native thin client into a particular directory (e.g. /usr/local/bin). I also made buildNativeThinClient have a file dependency on the classpath so that it can be incremental if the classpath hasn't changed. This is useful if the user has run buildNativeThinClient for testing and then decides to install it once it's been validated without having to rebuild (which takes a minimum of about 30 seconds on my laptop).
2020-07-27 23:33:19 +02:00
buildThinClient := {
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
val isFish = Def.spaceDelimited("").parsed.headOption.fold(false)(_ == "--fish")
val ext = if (isWin) ".bat" else if (isFish) ".fish" else ".sh"
val output = target.value.toPath / "bin" / s"${if (isFish) "fish-" else ""}client$ext"
java.nio.file.Files.createDirectories(output.getParent)
val cp = (Compile / fullClasspathAsJars).value.map(_.data)
val args =
if (isWin) "%*" else if (isFish) s"$$argv" else s"$$*"
java.nio.file.Files.write(
output,
s"""
|${if (isWin) "@echo off" else s"#!/usr/bin/env ${if (isFish) "fish" else "sh"}"}
|
|java -cp ${cp.mkString(java.io.File.pathSeparator)} sbt.client.Client --jna $args
""".stripMargin.linesIterator.toSeq.tail.mkString("\n").getBytes
)
output.toFile.setExecutable(true)
output
},
)
Coursier dependency resolution integration This adds dependency to LM implemented using Coursier. I had to copy paste a bunch of code from sbt-coursier-shared to break the dependency to sbt. `Global / useCoursier := false` or `-Dsbt.coursier=false` be used to opt-out of using Coursier for the dependency resolution.
2019-03-09 02:15:04 +01:00
/*
adding a fatjar release (aka sbt-big) to the build
2018-10-24 17:19:28 +02:00
lazy val sbtBig = (project in file(".big"))
.dependsOn(sbtProj)
.settings(
name := "sbt-big",
normalizedName := "sbt-big",
crossPaths := false,
assemblyShadeRules.in(assembly) := {
val packagesToBeShaded = Seq(
"fastparse",
"jawn",
"scalapb",
)
packagesToBeShaded.map( prefix => {
ShadeRule.rename(s"$prefix.**" -> s"sbt.internal.$prefix.@1").inAll
})
},
assemblyMergeStrategy in assembly := {
case "LICENSE" | "NOTICE" => MergeStrategy.first
case x => (assemblyMergeStrategy in assembly).value(x)
},
artifact.in(Compile, packageBin) := artifact.in(Compile, assembly).value,
assemblyOption.in(assembly) ~= { _.copy(includeScala = false) },
addArtifact(artifact.in(Compile, packageBin), assembly),
pomPostProcess := { node =>
new RuleTransformer(new RewriteRule {
override def transform(node: XmlNode): XmlNodeSeq = node match {
case e: Elem if node.label == "dependency" =>
Comment(
"the dependency that was here has been absorbed via sbt-assembly"
)
case _ => node
}
}).transform(node).head
},
)
format build.sbt
2019-05-11 09:42:06 +02:00
*/
adding a fatjar release (aka sbt-big) to the build
2018-10-24 17:19:28 +02:00
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
// util projects used by Zinc and Lm
lazy val lowerUtils = (project in (file("internal") / "lower"))
.aggregate(lowerUtilProjects.map(p => LocalProject(p.id)): _*)
.settings(
publish / skip := true,
crossScalaVersions := Nil,
)
lazy val upperModules = (project in (file("internal") / "upper"))
Exclude bundledLauncherProj from upperModules
2020-11-15 03:22:29 +01:00
.aggregate(
((allProjects diff lowerUtilProjects)
diff Seq(bundledLauncherProj)).map(p => LocalProject(p.id)): _*
)
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
.settings(
publish / skip := true,
crossScalaVersions := Nil,
)
WatchSource = sbt.internal.io.Source Ref #3438
2017-08-28 06:42:26 +02:00
lazy val sbtIgnoredProblems = {
Merge branch '1.0.x' into wip/bump
2017-11-29 22:45:02 +01:00
Vector(
Fix MiMa
2019-10-17 23:27:43 +02:00
exclude[IncompatibleSignatureProblem]("sbt.package.some"),
exclude[IncompatibleSignatureProblem]("sbt.package.inThisBuild"),
exclude[IncompatibleSignatureProblem]("sbt.package.inConfig"),
exclude[IncompatibleSignatureProblem]("sbt.package.inTask"),
exclude[IncompatibleSignatureProblem]("sbt.package.inScope"),
update mimaPreviousArtifacts. add sbt 1.1.0
2018-01-10 04:48:07 +01:00
exclude[MissingClassProblem]("buildinfo.BuildInfo"),
exclude[MissingClassProblem]("buildinfo.BuildInfo$"),
WatchSource = sbt.internal.io.Source Ref #3438
2017-08-28 06:42:26 +02:00
// Added more items to Import trait.
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$WatchSource_="),
Merge branch '1.0.x' into wip/bump
2017-11-29 22:45:02 +01:00
exclude[ReversedMissingMethodProblem]("sbt.Import.WatchSource"),
Add support for managed task inputs In my recent changes to watch, I have been moving towards a world in which sbt manages the file inputs and outputs at the task level. The main idea is that we want to enable a user to specify the inputs and outputs of a task and have sbt able to track those inputs across multiple task evaluations. Sbt should be able to automatically trigger a build when the inputs change and it also should be able to avoid task evaluation if non of the inputs have changed. The former case of having sbt automatically watch the file inputs of a task has been present since watch was refactored. In this commit, I make it possible for the user to retrieve the lists of new, modified and deleted files. The user can then avoid task evaluation if none of the inputs have changed. To implement this, I inject a number of new settings during project load if the fileInputs setting is defined for a task. The injected settings are: allPathsAndAttributes -- this retrieves all of the paths described by the fileInputs for the task along with their attributes fileStamps -- this retrieves all of the file stamps for the files returned by allPathsAndAttributes Using these two injected tasks, I also inject a number of derived tasks, such as allFiles, which returns all of the regular files returned by allPathsAndAttributes and changedFiles, which returns all of the regular files that have been modified since the last run. Using these injected settings, the user is able to write tasks that avoid evaluation if the inputs haven't changed. foo / fileInputs += baseDirectory.value.toGlob / ** / "*.scala" foo := { foo.previous match { case Some(p) if (foo / changedFiles).value.isEmpty => p case _ => fooImpl((foo / allFiles).value } } To make this whole mechanism work, I add a private task key: val fileAttributeMap = taskKey[java.util.HashMap[Path, Stamp]]("...") This keeps track of the stamps for all of the files that are managed by sbt. The fileStamps task will first look for the stamp in the attribute map and, only if it is not present, it will update the cache. This allows us to ensure that a given file will only be stamped once per task evaluation run no matter how the file inputs are specified. Moreover, in a continuous build, I'm able to reuse the attribute map which can significantly reduce latency because the default file stamping implementation used by zinc is fairly expensive (it can take anywhere between 300-1500ms to stamp 5000 8kb source files on my mac). I also renamed some of the watch related keys to be a bit more clear.
2019-04-24 02:00:13 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.AnyPath"),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$**_="),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$*_="),
Simplify file management settings I decided that there were too many settings related to the file management that did similar things and had similar names but did slightly different things. To improve this, I introduce the ChangedFiles class to sbt.nio.file and switch to having just two task for file input and output retrieval: all(Input|Output)Files and changed(Input|Output)Files. If, for example, changedInputFiles returns None that means that either the task has not yet been run or there were no changes. If there have been any changes, then it will return Some(changes) and the user can extract the relevant changes that they are interested in. The code may be slightly more verbose in a few places, but I think it's worth it for the conceptual clarity.
2019-04-30 21:02:28 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$ChangedFiles_="),
Add support for managed task inputs In my recent changes to watch, I have been moving towards a world in which sbt manages the file inputs and outputs at the task level. The main idea is that we want to enable a user to specify the inputs and outputs of a task and have sbt able to track those inputs across multiple task evaluations. Sbt should be able to automatically trigger a build when the inputs change and it also should be able to avoid task evaluation if non of the inputs have changed. The former case of having sbt automatically watch the file inputs of a task has been present since watch was refactored. In this commit, I make it possible for the user to retrieve the lists of new, modified and deleted files. The user can then avoid task evaluation if none of the inputs have changed. To implement this, I inject a number of new settings during project load if the fileInputs setting is defined for a task. The injected settings are: allPathsAndAttributes -- this retrieves all of the paths described by the fileInputs for the task along with their attributes fileStamps -- this retrieves all of the file stamps for the files returned by allPathsAndAttributes Using these two injected tasks, I also inject a number of derived tasks, such as allFiles, which returns all of the regular files returned by allPathsAndAttributes and changedFiles, which returns all of the regular files that have been modified since the last run. Using these injected settings, the user is able to write tasks that avoid evaluation if the inputs haven't changed. foo / fileInputs += baseDirectory.value.toGlob / ** / "*.scala" foo := { foo.previous match { case Some(p) if (foo / changedFiles).value.isEmpty => p case _ => fooImpl((foo / allFiles).value } } To make this whole mechanism work, I add a private task key: val fileAttributeMap = taskKey[java.util.HashMap[Path, Stamp]]("...") This keeps track of the stamps for all of the files that are managed by sbt. The fileStamps task will first look for the stamp in the attribute map and, only if it is not present, it will update the cache. This allows us to ensure that a given file will only be stamped once per task evaluation run no matter how the file inputs are specified. Moreover, in a continuous build, I'm able to reuse the attribute map which can significantly reduce latency because the default file stamping implementation used by zinc is fairly expensive (it can take anywhere between 300-1500ms to stamp 5000 8kb source files on my mac). I also renamed some of the watch related keys to be a bit more clear.
2019-04-24 02:00:13 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$AnyPath_="),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$Glob_="),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$RecursiveGlob_="),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$RelativeGlob_="),
exclude[ReversedMissingMethodProblem]("sbt.Import.*"),
exclude[ReversedMissingMethodProblem]("sbt.Import.**"),
Simplify file management settings I decided that there were too many settings related to the file management that did similar things and had similar names but did slightly different things. To improve this, I introduce the ChangedFiles class to sbt.nio.file and switch to having just two task for file input and output retrieval: all(Input|Output)Files and changed(Input|Output)Files. If, for example, changedInputFiles returns None that means that either the task has not yet been run or there were no changes. If there have been any changes, then it will return Some(changes) and the user can extract the relevant changes that they are interested in. The code may be slightly more verbose in a few places, but I think it's worth it for the conceptual clarity.
2019-04-30 21:02:28 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.ChangedFiles"),
Add support for managed task inputs In my recent changes to watch, I have been moving towards a world in which sbt manages the file inputs and outputs at the task level. The main idea is that we want to enable a user to specify the inputs and outputs of a task and have sbt able to track those inputs across multiple task evaluations. Sbt should be able to automatically trigger a build when the inputs change and it also should be able to avoid task evaluation if non of the inputs have changed. The former case of having sbt automatically watch the file inputs of a task has been present since watch was refactored. In this commit, I make it possible for the user to retrieve the lists of new, modified and deleted files. The user can then avoid task evaluation if none of the inputs have changed. To implement this, I inject a number of new settings during project load if the fileInputs setting is defined for a task. The injected settings are: allPathsAndAttributes -- this retrieves all of the paths described by the fileInputs for the task along with their attributes fileStamps -- this retrieves all of the file stamps for the files returned by allPathsAndAttributes Using these two injected tasks, I also inject a number of derived tasks, such as allFiles, which returns all of the regular files returned by allPathsAndAttributes and changedFiles, which returns all of the regular files that have been modified since the last run. Using these injected settings, the user is able to write tasks that avoid evaluation if the inputs haven't changed. foo / fileInputs += baseDirectory.value.toGlob / ** / "*.scala" foo := { foo.previous match { case Some(p) if (foo / changedFiles).value.isEmpty => p case _ => fooImpl((foo / allFiles).value } } To make this whole mechanism work, I add a private task key: val fileAttributeMap = taskKey[java.util.HashMap[Path, Stamp]]("...") This keeps track of the stamps for all of the files that are managed by sbt. The fileStamps task will first look for the stamp in the attribute map and, only if it is not present, it will update the cache. This allows us to ensure that a given file will only be stamped once per task evaluation run no matter how the file inputs are specified. Moreover, in a continuous build, I'm able to reuse the attribute map which can significantly reduce latency because the default file stamping implementation used by zinc is fairly expensive (it can take anywhere between 300-1500ms to stamp 5000 8kb source files on my mac). I also renamed some of the watch related keys to be a bit more clear.
2019-04-24 02:00:13 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.RecursiveGlob"),
exclude[ReversedMissingMethodProblem]("sbt.Import.Glob"),
exclude[ReversedMissingMethodProblem]("sbt.Import.RelativeGlob"),
Merge branch '1.0.x' into wip/bump
2017-11-29 22:45:02 +01:00
// Dropped in favour of kind-projector's polymorphic lambda literals
exclude[DirectMissingMethodProblem]("sbt.Import.Param"),
exclude[DirectMissingMethodProblem]("sbt.package.Param"),
Import SemanticSelector
2018-07-01 09:13:09 +02:00
exclude[ReversedMissingMethodProblem]("sbt.Import.SemanticSelector"),
exclude[ReversedMissingMethodProblem]("sbt.Import.sbt$Import$_setter_$SemanticSelector_="),
Merge branch '1.0.x' into wip/bump
2017-11-29 22:45:02 +01:00
// Dropped in favour of plain scala.Function, and its compose method
exclude[DirectMissingMethodProblem]("sbt.package.toFn1"),
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
WatchSource = sbt.internal.io.Source Ref #3438
2017-08-28 06:42:26 +02:00
}
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
Don't fail loading the build if npm is missing or we are on Windows
2017-10-29 14:37:53 +01:00
def runNpm(command: String, base: File, log: sbt.internal.util.ManagedLogger) = {
import scala.sys.process._
try {
Fix build so it works on Windows
2017-12-19 06:17:46 +01:00
val exitCode = Process(s"npm $command", Option(base)) ! log
Don't fail loading the build if npm is missing or we are on Windows
2017-10-29 14:37:53 +01:00
if (exitCode != 0) throw new Exception("Process returned exit code: " + exitCode)
} catch {
case e: java.io.IOException => log.warn("failed to run npm " + e.getMessage)
}
}
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
lazy val vscodePlugin = (project in file("vscode-sbt-scala"))
.settings(
sbt 1.4.6 and some Metals settings
2021-01-10 20:18:22 +01:00
bspEnabled := false,
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
crossPaths := false,
crossScalaVersions := Seq(baseScalaVersion),
skip in publish := true,
compile in Compile := {
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
val _ = update.value
Don't fail loading the build if npm is missing or we are on Windows
2017-10-29 14:37:53 +01:00
runNpm("run compile", baseDirectory.value, streams.value.log)
sbt.internal.inc.Analysis.empty
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
},
update := {
val old = update.value
val t = target.value / "updated"
val base = baseDirectory.value
Print npm output, handle exit code in case of errors
2017-10-06 02:26:59 +02:00
val log = streams.value.log
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
if (t.exists) ()
else {
Don't fail loading the build if npm is missing or we are on Windows
2017-10-29 14:37:53 +01:00
runNpm("install", base, log)
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
IO.touch(t)
}
old
},
cleanFiles ++= {
val base = baseDirectory.value
Vector(
target.value / "updated",
format build.sbt
2019-05-11 09:42:06 +02:00
base / "node_modules",
base / "client" / "node_modules",
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
base / "client" / "server",
base / "client" / "out",
format build.sbt
2019-05-11 09:42:06 +02:00
base / "server" / "node_modules"
) filter { _.exists }
begins language server protocol This is the first cut for the Language Server Protocol on top of server that is still work in progress. With this change, sbt is able to invoke `compile` task on saving files in VS Code.
2017-10-02 09:33:29 +02:00
}
)
Allow RunSourceFromMain to use launcher The repo overrides scripted test relies on using the launcher to modify the default resolvers. To support this, I extended the scripted launcher to use the bundled sbt launcher if it is passed in via the `-Dsbt.launch.jar` system property.
2020-01-13 01:50:29 +01:00
def scriptedTask(launch: Boolean): Def.Initialize[InputTask[Unit]] = Def.inputTask {
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
val _ = publishLocalBinAll.value
Allow RunSourceFromMain to use launcher The repo overrides scripted test relies on using the launcher to modify the default resolvers. To support this, I extended the scripted launcher to use the bundled sbt launcher if it is passed in via the `-Dsbt.launch.jar` system property.
2020-01-13 01:50:29 +01:00
val launchJar = s"-Dsbt.launch.jar=${(bundledLauncherProj / Compile / packageBin).value}"
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
Scripted.doScripted(
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
(scalaInstance in scriptedSbtReduxProj).value,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
scriptedSource.value,
scriptedBufferLog.value,
Cleanup local Scripted plugin
2018-01-24 14:42:18 +01:00
Def.setting(Scripted.scriptedParser(scriptedSource.value)).parsed,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
scriptedPrescripted.value,
Allow RunSourceFromMain to use launcher The repo overrides scripted test relies on using the launcher to modify the default resolvers. To support this, I extended the scripted launcher to use the bundled sbt launcher if it is passed in via the `-Dsbt.launch.jar` system property.
2020-01-13 01:50:29 +01:00
scriptedLaunchOpts.value ++ (if (launch) Some(launchJar) else None),
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
scalaVersion.value,
version.value,
Prepend scala instance jars to sbt classpath When using the launcher's classpath for the metabuild, the scala-compiler jar can be missing. This is because the managedJars only method returns the scala-library jar and not the rest of the scala instance. To fix this, we can always prepend the scala instance jars to the classpath. In order to simulate the issue in scripted, I had to manually remove the scala-compiler.jar from the scripted classpath or else the scripted test that I added doesn't actually do anything because the scala-compiler.jar would end up on the app.provider.mainClasspath. Fixes #4452
2020-11-20 21:17:59 +01:00
(scriptedSbtReduxProj / Test / fullClasspathAsJars).value
.map(_.data)
.filterNot(_.getName.contains("scala-compiler")),
Use logger in scripted instead of println
2019-11-17 21:34:19 +01:00
streams.value.log
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
}
lazy val publishLauncher = TaskKey[Unit]("publish-launcher")
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
def allProjects =
Seq(
Upgrade util/lm/zinc & config build for util modules Welcome back home!
2017-06-26 12:38:37 +02:00
logicProj,
completeProj,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
testingProj,
testAgentProj,
taskProj,
stdTaskProj,
runProj,
create scripted-sbt-redux Fixes #4241 Fixes #4242 This introduces a new subproject named scripted-sbt-redux. The purpose of this new subproject is to workaround the 'sbt.test` package vs `Keys.test` key confusion (#4242) while maintaining the forward compatibility of 0.13.17's sbt cross testing ^^ (#4241). The new subproject uses `sbt.scriptedtest` package name, and that's the one that will be used by the mothership. Meanwhile "scripted-sbt" subproject will also be published for compatibility purpose.
2018-07-10 06:58:45 +02:00
scriptedSbtReduxProj,
scriptedSbtOldProj,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
scriptedPluginProj,
Split to MiniDependencyTreePlugin Ref https://github.com/sbt/sbt/pull/5880 This split the dependency-graph plugin into MiniDependencyTreePlugin and DependencyTreePlugin.
2020-09-23 03:21:01 +02:00
dependencyTreeProj,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
protocolProj,
actionsProj,
commandProj,
mainSettingsProj,
In-source zinc's LM integration code
2019-04-18 09:14:04 +02:00
zincLmIntegrationProj,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
mainProj,
sbtProj,
fix build
2017-05-26 06:59:49 +02:00
bundledLauncherProj,
Add sbt client project This project is used to create client executables. The implementation is pure java but we can build graalvm native-images from the java main class. There are two versions of the client. One of them uses the ipcsocket jni implementation to connect to the sbt server while the other uses jna. It is necessary to use jni for the graalvm native-image tool to work. Otherwise the two approaches should be identical.
2020-06-22 01:48:33 +02:00
sbtClientProj,
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
) ++ lowerUtilProjects
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
// These need to be cross published to 2.12 and 2.13 for Zinc
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
lazy val lowerUtilProjects =
Seq(
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
collectionProj,
coreMacrosProj,
Update build.sbt to handle util projects As part of re-integrating util into the sbt main project, I had to update the build.sbt and a few dependencies (like the contraband plugin).
2019-12-08 00:49:13 +01:00
utilCache,
utilControl,
utilInterface,
utilLogging,
utilPosition,
utilRelation,
utilScripted,
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
utilTracking
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
)
Fix build
2015-02-03 04:44:02 +01:00
Drop myProvided from the build Introduces by Mark in d928047678624b51c6d240eb63d4df91179354ef. Dropped because Project#copy no longer exists (publically) in sbt 1. It looks like it might have been added to deal with transitive dependencies of scala-compiler, possibly JLine. Now it looks like it's only used by launcher-interface, which has 0 dependencies.
2017-05-08 15:08:40 +02:00
lazy val nonRoots = allProjects.map(p => LocalProject(p.id))
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
1.2.1-SNAPSHOT
2018-07-31 02:28:42 +02:00
ThisBuild / scriptedBufferLog := true
format build.sbt
2019-05-11 09:42:06 +02:00
ThisBuild / scriptedPrescripted := { _ =>
}
1.2.1-SNAPSHOT
2018-07-31 02:28:42 +02:00
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
def otherRootSettings =
Seq(
Allow RunSourceFromMain to use launcher The repo overrides scripted test relies on using the launcher to modify the default resolvers. To support this, I extended the scripted launcher to use the bundled sbt launcher if it is passed in via the `-Dsbt.launch.jar` system property.
2020-01-13 01:50:29 +01:00
scripted := scriptedTask(false).evaluated,
scriptedUnpublished := scriptedTask(false).evaluated,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
scriptedSource := (sourceDirectory in sbtProj).value / "sbt-test",
Add scripted watchTriggers This allows the scripted test files to trigger a continuous scripted build.
2019-05-25 20:28:34 +02:00
watchTriggers in scripted += scriptedSource.value.toGlob / **,
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
watchTriggers in scriptedUnpublished := (watchTriggers in scripted).value,
Forward -Dsbt.ivy.home
2019-12-30 01:26:05 +01:00
scriptedLaunchOpts := List("-Xmx1500M", "-Xms512M", "-server") :::
(sys.props.get("sbt.ivy.home") match {
case Some(home) => List(s"-Dsbt.ivy.home=$home")
case _ => Nil
}),
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
publishLocalBinAll := {
val _ = (Compile / publishLocalBin).all(scriptedProjects).value
},
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
aggregate in bintrayRelease := false,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
) ++ inConfig(Scripted.RepoOverrideTest)(
Seq(
Format the build
2017-06-23 18:58:00 +02:00
scriptedLaunchOpts := List(
"-Xmx1500M",
"-Xms512M",
"-server",
"-Dsbt.override.build.repos=true",
s"""-Dsbt.repository.config=${scriptedSource.value / "repo.config"}"""
Forward -Dsbt.ivy.home
2019-12-30 01:26:05 +01:00
) :::
(sys.props.get("sbt.ivy.home") match {
case Some(home) => List(s"-Dsbt.ivy.home=$home")
case _ => Nil
}),
Allow RunSourceFromMain to use launcher The repo overrides scripted test relies on using the launcher to modify the default resolvers. To support this, I extended the scripted launcher to use the bundled sbt launcher if it is passed in via the `-Dsbt.launch.jar` system property.
2020-01-13 01:50:29 +01:00
scripted := scriptedTask(true).evaluated,
scriptedUnpublished := scriptedTask(true).evaluated,
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
scriptedSource := (sourceDirectory in sbtProj).value / "repo-override-test"
format build.sbt
2019-05-11 09:42:06 +02:00
)
)
Adds a scripted test that tests repo override
2016-04-24 20:23:48 +02:00
Fix java version check, and use scope filter
2014-12-18 19:14:04 +01:00
lazy val docProjects: ScopeFilter = ScopeFilter(
format build.sbt
2019-05-11 09:42:06 +02:00
inAnyProject -- inProjects(
sbtRoot,
sbtProj,
scriptedSbtReduxProj,
scriptedSbtOldProj,
add aggregate project for lower utils and upper modules
2019-12-27 06:24:03 +01:00
scriptedPluginProj,
upperModules,
lowerUtils,
format build.sbt
2019-05-11 09:42:06 +02:00
),
Fix java version check, and use scope filter
2014-12-18 19:14:04 +01:00
inConfigurations(Compile)
Multi-project build.sbt
2014-12-18 05:38:10 +01:00
)
Add swoval java formatting plugin The swoval javafmt plugin uses the google java formatter (which I believe is the only widely used java formatter) to format source files. It does not provide an automatic javafmtOnCompile method like the scalafmt plugin so I had to manually implement that functionality. In general the java formatter is much faster than scalafmt so the impact of having javafmtOnCompile set to true is very low.
2020-01-14 23:01:17 +01:00
lazy val javafmtOnCompile = taskKey[Unit]("Formats java sources before compile")
Explicitly set scripted and server test classpath This commit makes it so that the scalaVersion, sbtVersion and classpath are always passed in as parameters to any method that creates an sbt server -- either for scripted or for the sbt server tests. By making that change, I was able to change the implementation of scripted in the sbt project to use publishLocalBin instead of publishLocal. This makes the scripted tests start much faster (doc alone can easily take 30 second) with messing with the build to exclude slow tasks from publishLocal. As part of this change, I removed the test dependency on scriptedSbtRedux for sbtProj and instead had scriptedSbtRedux depend on sbtProj. This allowed me to remove some messy LocalProject logic in the resourceGenerators for scriptedSbtReduxProj. I also had to remove a number of imports in the scriptedSbtReduxProj because the definitions available in the sbt package object became available. I also removed the dependency on sbt-buildinfo and instead pass the values from the build into test classes using scalatest properties. I ran into a number of minor issues with the build info plugin, namely that I couldn't get fullClasspathAsJars to reliably run as a BuildInfo key. It also is somewhat more clear to me to just rely on the built in scalatest functionality. The big drawback is that the scalatest properties can only be strings, but that restriction isn't really a problem here (strangely the TestData structure has a field configMap which is effectively Map[String, Any] but Any is actually always String given how the TestData is created as part of framework initialization. Since scripted no longer publishes, scriptedUnpublished is now effectively an alias for scripted. To get publishLocalBin working, I had to copy private code from IvyXml.scala into PublishBinPlugin. Once we publish a new version of sbt, we can remove the copied code and invoke IvyXml.makeIvyXmlBefore directly.
2020-01-12 04:52:36 +01:00
lazy val scriptedProjects = ScopeFilter(inAnyProject -- inProjects(vscodePlugin))
Fixing cross building
2014-12-18 23:40:20 +01:00
def customCommands: Seq[Setting[_]] = Seq(
Use Scala 2.12.1 Bump up the Scala version used by sbt to 2.12.1. Most changes are migration of the integration tests.
2017-01-15 07:44:05 +01:00
commands += Command.command("setupBuildScala212") { state =>
s"""set scalaVersion in ThisBuild := "$scala212" """ ::
Fixing cross building
2014-12-18 23:40:20 +01:00
state
},
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
commands += Command.command("whitesourceOnPush") { state =>
sys.env.get("TRAVIS_EVENT_TYPE") match {
case Some("push") =>
"whitesourceCheckPolicies" ::
format build.sbt
2019-05-11 09:42:06 +02:00
"whitesourceUpdate" ::
state
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
case _ => state
}
},
Fixing cross building
2014-12-18 23:40:20 +01:00
commands += Command.command("release-sbt-local") { state =>
Fixing precompiled and nightly build We noticed that -SNAPSHOT is being published as our nightly. This is because "wow" command (or ++) does not replay version injected by stamp-version.
2015-02-25 18:31:21 +01:00
"clean" ::
Apply Scalafmt formatting
2017-04-21 09:14:31 +02:00
"so compile" ::
"so publishLocal" ::
"reload" ::
state
Fixing cross building
2014-12-18 23:40:20 +01:00
},
add publishLocalAllModule command
2018-02-21 08:28:33 +01:00
commands += Command.command("publishLocalAllModule") { state =>
val extracted = Project.extract(state)
import extracted._
format build.sbt
2019-05-11 09:42:06 +02:00
val sv = get(scalaVersion)
val projs = structure.allProjectRefs
val ioOpt = projs find { case ProjectRef(_, id) => id == "ioRoot"; case _ => false }
add publishLocalAllModule command
2018-02-21 08:28:33 +01:00
val utilOpt = projs find { case ProjectRef(_, id) => id == "utilRoot"; case _ => false }
format build.sbt
2019-05-11 09:42:06 +02:00
val lmOpt = projs find { case ProjectRef(_, id) => id == "lmRoot"; case _ => false }
add publishLocalAllModule command
2018-02-21 08:28:33 +01:00
val zincOpt = projs find { case ProjectRef(_, id) => id == "zincRoot"; case _ => false }
format build.sbt
2019-05-11 09:42:06 +02:00
(ioOpt map { case ProjectRef(build, _) => "{" + build.toString + "}/publishLocal" }).toList :::
(utilOpt map { case ProjectRef(build, _) => "{" + build.toString + "}/publishLocal" }).toList :::
(lmOpt map { case ProjectRef(build, _) => "{" + build.toString + "}/publishLocal" }).toList :::
(zincOpt map {
case ProjectRef(build, _) =>
val zincSv = get(scalaVersion in ProjectRef(build, "zinc"))
val csv = get(crossScalaVersions in ProjectRef(build, "compilerBridge")).toList
(csv flatMap { bridgeSv =>
s"++$bridgeSv" :: ("{" + build.toString + "}compilerBridge/publishLocal") :: Nil
}) :::
List(s"++$zincSv", "{" + build.toString + "}/publishLocal")
}).getOrElse(Nil) :::
List(s"++$sv", "publishLocal") :::
state
add publishLocalAllModule command
2018-02-21 08:28:33 +01:00
},
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
commands += Command.command("releaseLowerUtils") { state =>
// TODO - Any sort of validation
"clean" ::
"+lowerUtils/compile" ::
"+lowerUtils/publishSigned" ::
s"++$scala212" ::
state
},
commands += Command.command("release") { state =>
Fixing cross building
2014-12-18 23:40:20 +01:00
// TODO - Any sort of validation
Fixing precompiled and nightly build We noticed that -SNAPSHOT is being published as our nightly. This is because "wow" command (or ++) does not replay version injected by stamp-version.
2015-02-25 18:31:21 +01:00
"clean" ::
Fix build to publish M6
2017-05-30 08:44:13 +02:00
"conscriptConfigs" ::
Some new modules need to be cross published
2020-09-20 21:02:09 +02:00
"upperModules/compile" ::
"upperModules/publishSigned" ::
bundledLauncherProj needs to be published
2020-11-16 05:38:48 +01:00
"bundledLauncherProj/publishSigned" ::
fix launcher re-publication. * The rebundled sbt launcher is now pushed into the old location again.
2015-03-24 23:32:56 +01:00
"bundledLauncherProj/publishLauncher" ::
Adds release-nightly command
2015-02-21 03:09:43 +01:00
state
},
Fixing cross building
2014-12-18 23:40:20 +01:00
)
Add, configure & enforce sbt-whitesource
2018-01-11 15:13:21 +01:00
format build.sbt
2019-05-11 09:42:06 +02:00
ThisBuild / whitesourceProduct := "Lightbend Reactive Platform"
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
ThisBuild / whitesourceAggregateProjectName := {
// note this can get detached on tag build etc
WhiteSource integration
2020-01-15 23:45:27 +01:00
val b = sys.process.Process("git rev-parse --abbrev-ref HEAD").!!.trim
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
val Stable = """1\.([0-9]+)\.x""".r
b match {
case Stable(y) => "sbt-1." + y.toString + "-stable"
case _ => "sbt-master"
}
}
ThisBuild / whitesourceAggregateProjectToken := {
(ThisBuild / whitesourceAggregateProjectName).value match {
case "sbt-master" => "e7a1e55518c0489a98e9c7430c8b2ccd53d9f97c12ed46148b592ebe4c8bf128"
WhiteSource integration
2020-01-15 23:45:27 +01:00
case "sbt-1.3-stable" => "7e38cbb4d2fc4599835cd5d2cfb41b150597a4147b15424bb65841664ab2ec0d"
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
case "sbt-1.2-stable" => "54f2313767aa47198971e65595670ee16e1ad0000d20458588e72d3ac2c34763"
case _ => "" // it's ok to fail here
}
}
format build.sbt
2019-05-11 09:42:06 +02:00
ThisBuild / whitesourceIgnoredScopes ++= Seq("plugin", "scalafmt", "sxr")
ThisBuild / whitesourceFailOnError := sys.env.contains("WHITESOURCE_PASSWORD") // fail if pwd is present
define whitesourceOnPush whitesourceOnPush calls whitesourceCheckPolicies and whitesourceUpdate on push. Since Travis CI secrets are not available during PR from a fork, there's no point in calling these during the PR validation.
2018-12-14 01:31:56 +01:00
ThisBuild / whitesourceForceCheckAllDependencies := true