I have a built.sbt that references a child project's main class as its own main class:
lazy val akka = (project in file("."))
.aggregate(api)
.dependsOn(api)
.enablePlugins(JavaAppPackaging)
lazy val api = project in file("api")
scalaVersion := "2.11.6"
// This is referencing API code
mainClass in (Compile, run) := Some("maslow.akka.cluster.node.ClusterNode")
artifactName := { (sv: ScalaVersion, module: ModuleID, artifact: Artifact) =>
s"""${artifact.name}.${artifact.extension}"""
}
name in Universal := name.value
packageName in Universal := name.value
However, each time I run sbt run I get the following error:
> run
[info] Updating {file:/Users/mark/dev/Maslow-Akka/}api...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] Updating {file:/Users/mark/dev/Maslow-Akka/}akka...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] Running maslow.akka.cluster.node.ClusterNode
[error] (run-main-0) java.lang.ClassNotFoundException: maslow.akka.cluster.node.ClusterNode
java.lang.ClassNotFoundException: maslow.akka.cluster.node.ClusterNode
at java.lang.ClassLoader.findClass(ClassLoader.java:530)
As I've been doing some research into the problem, I first switched to the project to api from akka and then opened up console. From there, it can't find the maslow package even though it most certainly exists. After that, I went into the api folder and ran sbt console and it accessed the aforementioned package just fine. After I do this, sbt run from the akka project works. Why?
The folder api is pulled in via git read-tree. There shouldn't be anything special about it. I'm using sbt 0.13.5
I think in a multi-project build a global line such as
mainClass in (Compile, run) := ...
will just be swallowed without consequences, as it doesn't refer to any project.
Probably the following works:
mainClass in (Compile, run) in ThisBuild := ...
Or you add it to the root project's settings:
lazy val akka = (project in file("."))
.aggregate(api)
.dependsOn(api)
.enablePlugins(JavaAppPackaging)
.settings(
mainClass in (Compile, run) := ...
)
The problem was this line: lazy val api = project in file("api")
From the docs:
When defining a dependency on another project, you provide a ProjectReference. In the simplest case, this is a Project object. (Technically, there is an implicit conversion Project => ProjectReference) This indicates a dependency on a project within the same build.
This indicates a dependency within the same build. Instead, what I needed was to use RootProject since api is an external build:
It is possible to declare a dependency on a project in a directory separate from the current build, in a git repository, or in a project packaged into a jar and accessible via http/https. These are referred to as external builds and projects. You can reference the root project in an external build with RootProject:
In order to solve this problem, I removed the project declarations out of build.sbt into project/Build.scala:
import sbt._
object MyBuild extends Build {
lazy val akka = Project("akka", file(".")).aggregate(api).dependsOn(api)
lazy val api = RootProject(file("api"))
}
To be clear, the problem was that my api sub-project was a ProjectRef and not a RootProject.
Related
I have an SBT multiproject structure, but for some reason sbt does not recognize the unmanaged jar when tests are run. The objective is to have a stub subproject without an actual implementation and add this as a "Provided" dependency to the Main class, it should detect the jars in the /lib folder when provided. The actual implementation in the .jar file simply prints a random string.
Here is the project structure.
./MainClass
./MainClass/lib/printsomethingexample_2.13-0.1.0-SNAPSHOT.jar
./MainClass/src/test/scala/Main.scala
./MainClass/src/main/scala/Main.scala
./stub/lib/printsomethingexample_2.13-0.1.0-SNAPSHOT.jar
./stub/src/main/scala/test/stub/Example.scala
./build.sbt
File main/scala/Main.scala
import test.stub.Example
object Main extends App {
Example.printSomething()
}
File test/scala/Main.scala
import org.scalatest.flatspec._
import test.stub.Example
class Main extends AnyFlatSpec {
"Unmanaged jar" should "work" in {
Example.printSomething()
}
}
scala/test/stub/Example.scala:
package test.stub
object Example {
def printSomething(): Unit = ???
}
build.sbt:
ThisBuild / version := "0.1.0-SNAPSHOT"
ThisBuild / scalaVersion := "2.13.10"
lazy val root = (project in file("."))
.settings(
name := "stubExample"
).aggregate(MainClass, stub)
lazy val stub = project
.in(file("stub"))
.settings(
name := "stub"
)
lazy val MainClass = project
.in(file("MainClass"))
.settings(
name := "MainClass",
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.14" % Test,
).dependsOn(`stub` % Provided)
When I run sbt "MainClass/runMain Main" it finds the unmanaged jars as expected and prints the string, but when I run sbt "MainClass/test" I get the following error:
[info] Main:
[info] Unmanaged jar
[info] - should work *** FAILED ***
[info] scala.NotImplementedError: an implementation is missing
Does anyone understand why the jars are not found?
*** EDIT ***
Here is the output of sbt "MainClass/runMain Main"
▶ sbt "MainClass/runMain Main"
[info] welcome to sbt 1.6.2 (Azul Systems, Inc. Java 1.8.0_312)
[info] loading global plugins from /Users/riccardo/.sbt/1.0/plugins
[info] loading project definition from /Users/riccardo/Documents/Projects/stubExample/project
[info] loading settings for project root from build.sbt ...
[info] set current project to stubExample (in build file:/Users/riccardo/Documents/Projects/stubExample/)
[info] running Main
Printed Something
The .jar has an implementation of test.stub.Example#printSomething (It is a different project)
package test.stub
object Example {
def printSomething(): Unit = println("Printed Something")
}
My expectation is that since the stub subproject is marked as Provided it should use the printSomething implementation from the jar in the classpath instead of the stub subproject, the stub subproject was marked as Provided and would expect it to be excluded from the classpath (maybe I don't understand how Provided works).
This behavior happens when running the main class as shown above, it uses the printSomething from the classpath in lib/printsomethingexample_2.13-0.1.0-SNAPSHOT.jar instead of using the stub that is not implemented. In my real life scenario, I need the dependency on the stub subproject.
If I remove the dependsOn the sbt test step works, but the project wouldn't compile without the unmanaged jars in the /lib folder, hence why we use a stub subproject as dependecy, just to make the project compile.
How do I make sbt include non-Java sources to published artifact ?
I'm using Kotlin plugin and can't figure out how to force sbt to include .kt file into published source jar. It only includes .java files.
A lot of people online suggest adding following code to sbt script but it doesn't help
mappings in (Compile, packageSrc) ++= {
val base = (sourceManaged in Compile).value
val files = (managedSources in Compile).value
files.map { f => (f, f.relativeTo(base).get.getPath) }
},
I also tried
includeFilter in (Compile, packageSrc) := "*.scala" || "*.java" || "*.kt",
Here is output of some variables in sbt console
sbt:collections> show unmanagedSourceDirectories
[info] * /home/expert/work/sideprojects/unoexperto/extensions-collections/src/main/scala
[info] * /home/expert/work/sideprojects/unoexperto/extensions-collections/src/main/java
[info] * /home/expert/work/sideprojects/unoexperto/extensions-collections/src/main/kotlin
sbt:collections> show unmanagedSources
[info] * /home/expert/work/sideprojects/unoexperto/extensions-collections/src/main/java/com/walkmind/extensions/collections/TestSomething.java
which plugin you use for kotlin?
https://github.com/pfn/kotlin-plugin has the option kotlinSource to configure where the source directory is located.
sbt packageBin compiled kotlin files and include them to output jar.
build.sbt
// define kotlin source directory
kotlinSource in Compile := baseDirectory.value / "src/main/kotlin",
src/main/kotlin/org.test
package org.test
fun main(args: Array<String>) {
println("Hello World!")
}
console
sbt compile
sbt packageBin
target/scala-2.13
jar include MainKt.class
and folder org/test contains MainKt.class too.
would this solve your problem?
I found a workaround for this in my project https://github.com/makiftutuncu/e. I made following: https://github.com/makiftutuncu/e/blob/master/project/Settings.scala#L105
Basically, I added following setting in SBT to properly generate sources artifact:
// Include Kotlin files in sources
packageConfiguration in Compile := {
val old = (packageConfiguration in Compile in packageSrc).value
val newSources = (sourceDirectories in Compile).value.flatMap(_ ** "*.kt" get)
new Package.Configuration(
old.sources ++ newSources.map(f => f -> f.getName),
old.jar,
old.options
)
}
For the documentation artifact, I added Gradle build to my Kotlin module. I set it up as shown here https://github.com/makiftutuncu/e/blob/master/e-kotlin/build.gradle.kts. This way, I make Gradle build generate the Dokka documentation. And finally, added following setting in SBT to run Gradle while building docs:
// Delegate doc generation to Gradle and Dokka
doc in Compile := {
import sys.process._
Process(Seq("./gradlew", "dokkaJavadoc"), baseDirectory.value).!
target.value / "api"
}
I admit, this is a lot of work just to get 2 artifacts but it did the trick for me. 🤷🏻 Hope this helps.
I'm developing a library that includes an sbt plugin. Naturally, I'm using sbt to build this (multi-project) library. My (simplified) project looks as follows:
myProject/ # Top level of library
-> models # One project in the multi-project sbt build.
-> src/main/scala/... # Defines common models for both sbt-plugin and framework
-> sbt-plugin # The sbt plugin build
-> src/main/scala/...
-> framework # The framework. Ideally, the sbt plugin is run as part of
-> src/main/scala/... # compiling this directory.
-> project/ # Multi-project build configuration
Is there a way to have the sbt-plugin defined in myProject/sbt-plugin be hooked into the build for myProject/framework all in a unified build?
Note: similar (but simpler) question: How to develop sbt plugin in multi-project build with projects that use it?
Is there a way to have the sbt-plugin defined in myProject/sbt-plugin be hooked into the build for myProject/framework all in a unified build?
I have a working example on Github eed3si9n/plugin-bootstrap. It's not super pretty, but it kind of works. We can take advantage of the fact that sbt is recursive.
The project directory is another build inside your build, which knows how to build your build. To distinguish the builds, we sometimes use the term proper build to refer to your build, and meta-build to refer to the build in project. The projects inside the metabuild can do anything any other project can do. Your build definition is an sbt project.
By extension, we can think of the sbt plugins to be library- or inter-project dependencies to the root project of your metabuild.
meta build definition (project/plugins.sbt)
In this example, think of the metabuild as a parallel universe or shadow world that has parallel multi-build structure as the proper build (root, model, sbt-plugin).
To reuse the source code from model and sbt-plugin subprojects in the proper build, we can re-create the multi-project build in the metabuild. This way we don't need to get into the circular dependency.
addSbtPlugin("com.eed3si9n" % "sbt-doge" % "0.1.5")
lazy val metaroot = (project in file(".")).
dependsOn(metaSbtSomething)
lazy val metaModel = (project in file("model")).
settings(
sbtPlugin := true,
scalaVersion := "2.10.6",
unmanagedSourceDirectories in Compile :=
mirrorScalaSource((baseDirectory in ThisBuild).value.getParentFile / "model")
)
lazy val metaSbtSomething = (project in file("sbt-plugin")).
dependsOn(metaModel).
settings(
sbtPlugin := true,
scalaVersion := "2.10.6",
unmanagedSourceDirectories in Compile :=
mirrorScalaSource((baseDirectory in ThisBuild).value.getParentFile / "sbt-plugin")
)
def mirrorScalaSource(baseDirectory: File): Seq[File] = {
val scalaSourceDir = baseDirectory / "src" / "main" / "scala"
if (scalaSourceDir.exists) scalaSourceDir :: Nil
else sys.error(s"Missing source directory: $scalaSourceDir")
}
When sbt loads up, it will build metaModel and metaSbtSomething first, and use metaSbtSomething as a plugin to your proper build.
If you have any other plugins you need you can just add it to project/plugins.sbt normally as I've added sbt-doge.
proper build (build.sbt)
The proper build looks like a normal multi-project build.
As you can see framework subproject uses SomethingPlugin. Important thing is that they share the source code, but the target directory is completely separated, so there are no interference once the proper build is loaded, and you are changing code around.
import Dependencies._
lazy val root = (project in file(".")).
aggregate(model, framework, sbtSomething).
settings(inThisBuild(List(
scalaVersion := scala210,
organization := "com.example"
)),
name := "Something Root"
)
// Defines common models for both sbt-plugin and framework
lazy val model = (project in file("model")).
settings(
name := "Something Model",
crossScalaVersions := Seq(scala211, scala210)
)
// The framework. Ideally, the sbt plugin is run as part of building this.
lazy val framework = (project in file("framework")).
enablePlugins(SomethingPlugin).
dependsOn(model).
settings(
name := "Something Framework",
crossScalaVersions := Seq(scala211, scala210),
// using sbt-something
somethingX := "a"
)
lazy val sbtSomething = (project in file("sbt-plugin")).
dependsOn(model).
settings(
sbtPlugin := true,
name := "sbt-something",
crossScalaVersions := Seq(scala210)
)
demo
In the SomethingPlugin example, I'm defining something task that uses foo.Model.x.
package foo
import sbt._
object SomethingPlugin extends AutoPlugin {
def requries = sbt.plugins.JvmPlugin
object autoImport {
lazy val something = taskKey[Unit]("")
lazy val somethingX = settingKey[String]("")
}
import autoImport._
override def projectSettings = Seq(
something := { println(s"something! ${Model.x}") }
)
}
Here's how we can invoke something task from the build:
Something Root> framework/something
something! 1
[success] Total time: 0 s, completed May 29, 2016 3:01:07 PM
1 comes from foo.Model.x, so this demonstrates that we are using the sbt-something plugin in framework subproject, and that the plugin is using metaModel.
I use the sbt 0.13.1 create the two modules, and I create project/MyBuild.scala to compile this two modules.
MyBuild.scala:
import sbt._
import Keys._
object MyBuild extends Build {
lazy val task = project.in(file("task"))
lazy val root = project.in(file(".")) aggregate(task) dependsOn task
}
When I change the scala library to 2.11.2 by set scalaHome. It will go to maven download the task.jar and failed, that's very strange. Is it a sbt bug?
There is the github test project address: test-sbt-0.13.1
This is because you have defined a custom scalaVersion in your main build.sbt which means it is defined for the root project only. The task project will use the default value:
jjst#ws11:test-sbt-0.13.1$ sbt
[...]
> projects
[info] In file:/home/users/jjost/dev/test-sbt-0.13.1/
[info] * root
[info] task
> show scalaVersion
[info] task/*:scalaVersion
[info] 2.10.4
[info] root/*:scalaVersion
[info] 2.11.2-local
As a consequence, artifacts generated by the task subproject won't be available for the root project to use.
You can solve this by making sure that your projects use the same scalaVersion. The easiest way to do so while keeping the same project structure would be to share common settings like the scala version across projects like so:
object MyBuild extends Build {
val commonSettings = Seq(
scalaVersion := "2.11.2-local",
scalaHome := Some(file("/usr/local/scala-2.11.2/"))
)
lazy val task = (project.in(file("task"))).
settings(commonSettings: _*)
lazy val root = (project.in(file("."))).
settings(commonSettings: _*).
aggregate(task).
dependsOn(task)
}
In practice, you might want to put common settings shared between projects in a dedicated file under project/common.scala, as recommended in Effective sbt.
I'd recommend you to move the sources of root project from root to subfolder (task2), and add them as aggregated. It will remove aggregating and depending on same project:
object MyBuild extends Build {
lazy val task = project.in(file("task"))
lazy val task2 = project.in(file("task2")) dependsOn task
lazy val root = project.in(file(".")) aggregate(task, task2)
}
This works for me, but it's strange that such non-standard project structure works fine with default scalaHome. Seems to be a problem in the way in which sbt resolves such dependency as external.
P.S. This answer doesn't cover the whole story. See #jjst's answer to clarify more.
Could you guys please explain to me how to set main class in SBT project ? I'm trying to use version 0.13.
My directory structure is very simple (unlike SBT's documentation). In the root folder I have build.sbt with following content
name := "sbt_test"
version := "1.0"
scalaVersion := "2.10.1-local"
autoScalaLibrary := false
scalaHome := Some(file("/Program Files (x86)/scala/"))
mainClass := Some("Hi")
libraryDependencies ++= Seq(
"org.scalatest" % "scalatest_2.10" % "2.0.M5b" % "test"
)
EclipseKeys.withSource := true
And I have subfolder project with single file Hi.scala which contains following code
object Hi {
def main(args: Array[String]) = println("Hi!")
}
I'm able to compile it by calling sbt compile but sbt run returns
The system cannot find the file C:\work\externals\sbt\bin\sbtconfig.txt.
[info] Loading project definition from C:\work\test_projects\sbt_test\project
[info] Set current project to sbt_test (in build file:/C:/work/test_projects/sbt_test/)
java.lang.RuntimeException: No main class detected.
at scala.sys.package$.error(package.scala:27)
[trace] Stack trace suppressed: run last compile:run for the full output.
[error] (compile:run) No main class detected.
[error] Total time: 0 s, completed Apr 8, 2013 6:14:41 PM
You need to put your application's source in src/main/scala/, project/ is for build definition code.
Try to use an object and extend it from App instead of using class
object Main extends App {
println("Hello from main scala object")
}
Here is how to specify main class
mainClass in (Compile,run) := Some("my.fully.qualified.MainClassName")
For custom modules in SBT (0.13), just enter on the SBT console:
project moduleX
[info] Set current project to moduleX (in build file:/path/to/Projects/)
> run
[info] Running main
to switch scope to moduleX, as define in Built.scala. All main classes within that scope will be detected automatically. Otherwise you get the same error of no main class detected.
For God's sake, SBT does not tell you that the default scope is not set. It has nothing to do with default versus non default source folders but only with SBT not telling anything that it doesn't know which module to use by default.
Big Hint to typesafe: PLEASE add a default output like:
[info] Project module is not set. Please use ''project moduleX'' set scope
or set in Built file (LinkToDocu)
at the end of SBT start to lower the level of frustration while using SBT on multi module projects.....
I had the same issue: was mode following the tutorial at http://www.scala-sbt.org/0.13/docs/Hello.html, and in my opinion, as a build tool sbt's interaction and error messages can be quite misleading to a newcomer.
It turned out, hours of head scratching later, that I missed the critical cd hello line in the example each time. :-(
If you have multiple main methods in your project you can add the following line to your build.sbt file:
val projectMainClass = "com.saeed.ApplicationMain"
mainClass in (Compile, run) := Some(projectMainClass)
If you want to specify the class that will be added to the manifest when your application is packaged as a JAR file, add this line to your build.sbt file:
mainClass in (Compile, packageBin) := Some(projectMainClass)
You can also specify main class using run-main command in sbt and activator to run:
sbt "run-main com.saeed.ApplicationMain"
or
activator "run-main com.saeed.ApplicationMain"
There are 4 options
you have 1 main class
sbt run and sbt will find main for you
you have 2 or more main classes
sbt run and sbt will propose to select which one you want to run.
Multiple main classes detected, select one to run:
[1] a.b.DummyMain1
[2] a.b.DummyMain2
Enter number:
You want to set main class manually.
mainClass in run := Some("a.b.DummyMain1")
You could run with main class as parameter
sbt runMain a.b.DummyMain1
If the Main class is in a different project then by setting the below command in build.sbt would work:
addCommandAlias("run", "; project_folder/run")
I had the same issue. Resolved it after adding PlayMinimalJava plugin in build.sbt.
Not sure how it got fixed, if someone can highlight how PlayMinimalJava solves it, would be great.
enablePlugins(PlayMinimalJava)
My build.sbt looks like this
organization := "org"
version := "1.0-SNAPSHOT"
scalaVersion := "2.13.1"
libraryDependencies += guice
enablePlugins(PlayMinimalJava)
Log
C:\Users\KulwantSingh\repository\pdfdemo>sbt run
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading settings for project pdfdemo-build from plugins.sbt ...
[info] Loading project definition from C:\Users\KulwantSingh\repository\pdfdemo\project
[info] Loading settings for project pdfdemo from build.sbt ...
[info] Set current project to pdfdemo (in build file:/C:/Users/KulwantSingh/repository/pdfdemo/)
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings.
--- (Running the application, auto-reloading is enabled) ---
[info] p.c.s.AkkaHttpServer - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
(Server started, use Enter to stop and go back to the console...)
[info] Compiling 6 Scala sources and 2 Java sources to C:\Users\KulwantSingh\repository\pdfdemo\target\scala-2.13\classes ...
[info] p.a.h.EnabledFilters - Enabled Filters (see <https://www.playframework.com/documentation/latest/Filters>):
play.filters.csrf.CSRFFilter
play.filters.headers.SecurityHeadersFilter
play.filters.hosts.AllowedHostsFilter
[info] play.api.Play - Application started (Dev) (no global state)
Incase if someone made a silly mistake like I did.
Check if your project is sbt-multi project.
If it is make sure to provide sbt moduleName/run instead sbt run
I keep making this mistaken when I switch between multi and single projects.