Say I have a project defined as follows:
val commonSettings = Seq(
name := "project1",
version := "1.0",
scalaVersion := "2.12.8",
unmanagedSourceDirectories in Compile +=
baseDirectory.value / ".." / "shared" / "src" / "main" / "scala"
)
val client = project.in(file("client"))
.settings(commonSettings: _*)
val server = project.in(file("server"))
.settings(commonSettings: _*)
And I have a second project that uses a REST api to communicate with this server. Thus the second project uses code defined in the shared source of the first. The second project cannot depend on the entire project1 as there are incompatibilities between the sbt versions for the two projects.
What do I need to add to my build.sbt and/or change in the first project in order for the second project to reference the shared source?
If project1 and project 2 are finally going to run independently it would be better if you write REST APIs to communicate in between them.
You can write an API in project2 and hit it from project1 to run the shared code of project2.
Otherwise, why not just replicate shared code from project2 to project1 ?
You can try jitpack, add below lines in your build.sbt to enable jitpack resolver and add appropriate dependencies
resolvers += "jitpack" at "https://jitpack.io"
// you can also use specific sha or tag instead of master-SNAPSHOT
libraryDependencies += "org.xyz" %% "project" % "master-SNAPSHOT"
Related
I have a set of .proto files (protobuf) which I generate java from using scalapb. I also have in the same sbt 2 sub-projects, one is scalaVersion 2.11 compatible (can't upgrade it to 2.12 due to missing packages) and the other one is scala 2.12.
I created a sub-project to hold my proto, and by default 2.12 is used and my 2.12 sub-project can use it, but my 2.11 can't.
I set the crossScalaVersions to 2.11/2.12, I compiled my project with both, which passed, but then even then I was unable to get the 2.11 sub-project to find that code.
I am "wondering" if that is something supported, or if there is a track I could use a single location to hold my .proto yet have my 2 sub-projects using the same sbt file use those.
lazy val scala212 = "2.12.13"
lazy val scala211 = "2.11.12"
lazy val supportedScalaVersion = List(scala212, scala211)
ThisBuild / scalaVersion := scala212
lazy val root = (project in file("."))
.aggregate(proto, subproject1, subproject2)
.settigns(
crossScalaVersions := Nil,
publish / skip := true
)
lazy val proto = project
.settings(
crossScalaVersions := supportedScalaVersions,
name := "proto",
libraryDependencies += "com.trueaccord.scalapb" %% "scalapb-runtime" % com.trueaccord.scalapb.compiler.Version.scalapbVersion % "protobuf",
PB.targets in Compile := Seq(
scalapb.gen(grpc = false) -> (sourceManaged in Compile).value / "protobuf"
)
)
lazy val subproject1 = project
.dependsOn(proto)
lazy val subproject2 = project
.settings(
scalaVersion := scala211
)
.dependsOn(proto)
So, from the above, if I do sbt "+ proto" I can compile both versions. If I do sbt subproject1/compile it works too. Using sbt subproject2/compile fails indicating that it cannot find the 2.11:proto jar file.
Either, I would like the above somehow to work nicely, or any other trick that I could generate the code from the same proto location but within subproject1/subproject2 would be appreciated.
You could try the sbt-projectmatrix plugin:
https://github.com/sbt/sbt-projectmatrix
The idea is to have separate sbt subprojects for the different Scala versions, so you can simply reference the relevant subproject when calling dependsOn.
I think this plugin is going to end up in sbt some day as it's a much better solution in general than the current built-in stateful cross compilation support, and it's developed by Eugene Yokota, who is also an sbt developer.
I'm trying to create a relatively simple sbt plugin to wrap grpc-swagger artifact.
Therefore, I've created a project with the following structure:
projectDir/
build.sbt
lib/grpc-swagger.jar <- the artifact I've downloaded
src/...
where build.sbt looks like the following:
ThisBuild / version := "0.0.1-SNAPSHOT"
ThisBuild / organization := "org.testPlugin"
ThisBuild / organizationName := "testPlugin"
lazy val root = (project in file("."))
.enable(SbtPlugin)
.settings(name := "grpc-swagger-test-plugin")
According to sbt docs, that's all I have to do in order to include an unmanaged dependecy, that is:
create a lib folder;
store the artifact in there;
However, when I do execute sbt compile publishLocal, the plugin published lacks of that external artifact.
So far I've tried to:
set exportJars := true flag
add Compile / unmanagedJars += file(lib/grpc-swagger.jar") (with also variations of the path)
manual fiddling to libraryDependecies using from file("lib/grpc-swagger.jar") specifier
but none so far seemed to work.
So how am I supposed to add an external artifact to a sbt plugin?
The proper solution to this problem is to publish the grpc-swagger library. If for whatever reason this can't be done from that library's build system, you can do it with sbt. Just add a simple subproject whose only job it is to publish that jar. It should work like so:
...
lazy val `grpc-swagger` = (project in file("."))
.settings(
name := "grpc-swagger",
Compile / packageBin := baseDirectory.value / "lib" / "grpc-swagger.jar",
// maybe other settings, such as grpc-swagger's libraryDependencies
)
lazy val root = (project in file("."))
.enable(SbtPlugin)
.settings(name := "grpc-swagger-test-plugin")
.dependsOn(`grpc-swagger`)
...
The pom file generated for the root project should now specify a dependency on grpc-swagger, and running the publish task in the grpc-swagger project will publish that jar along with a pom file.
That should be enough to make things work, but honestly, it's still a hack. The proper solution is to fix grpc-swagger's build system so you can publish an artifact from there and then just use it via libraryDependencies.
Say I want to include font-awesome in my webapp. So I define my build.sbt as follows:
val commonSettings = Seq(
name := "repro",
version := "1.0",
scalaVersion := "2.12.8",
unmanagedSourceDirectories in Compile +=
baseDirectory.value / ".." / "shared" / "src" / "main" / "scala"
)
val client = project.in(file("client"))
.settings(commonSettings: _*)
.settings(
npmDependencies in Compile ++= Seq(
"font-awesome" -> "4.7.0",
),
mainClass in Compile := Some("app.App"),
scalaJSUseMainModuleInitializer := true,
webpackBundlingMode := BundlingMode.LibraryOnly(),
)
.enablePlugins(ScalaJSPlugin)
.enablePlugins(ScalaJSBundlerPlugin)
val server = project.in(file("server"))
.settings(commonSettings: _*)
.settings(
npmAssets ++= NpmAssets.ofProject(client) { nodeModules =>
(nodeModules / "font-awesome").allPaths
}.value
)
.enablePlugins(WebScalaJSBundlerPlugin)
Can I configure this project so that my "package" command will then include the css in my target/webapp folder? Or is there another command I have to use?
In addition to your configuration, you have to add the following settings to the server project:
.settings(
scalaJSProjects := Seq(client),
pipelineStages in Assets := Seq(scalaJSPipeline),
managedClasspath in Runtime += (packageBin in Assets).value,
WebKeys.packagePrefix in Assets := "public/"
)
The first line introduces a dependency between the server project and the assets produced by the client project. The scalaJSProjects settings is introduced by the sbt-web-scalajs plugin.
The second line integrates the assets produced by the client project into the Web assets managed by sbt-web.
The third line tells sbt to include the assets produced by the sbt-web plugin to the classpath of the server.
The last line is optional, it simply puts the produced assets into the public/ resource directory, so that they are not mixed with other classpath resources which are not meant to be exposed to the outside world.
With this configuration, you can build the production assets with the following command:
> server/web-assets:package
Or, from a build file, by using the packageBin in Assets task.
This will produce a target/scala-2.12/repro_2.12-1.0-web-assets.jar file containing the JavaScript bundle produced by Webpack on your client project, as well as the font-awesome/ directory.
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'm just starting out trying to set up a workflow with scala and sbt, and I'm having trouble with my repository. I am trying to publish a simple test library, which is composed of two projects, and use it from another program.
My source library's build contains the following:
val sharedSettings = Seq(
name := "test-lib",
organization := "com.example",
version := "0.1-SNAPSHOT",
scalaVersion := "2.11.0",
publishTo := Some("Artifactory Realm" at "http://localhost:8081/artifactory/libs-snapshot-local"),
publishMavenStyle := true,
credentials += Credentials(Path.userHome / ".ivy2" / ".credentials")
)
lazy val root = project.in(file(".")).settings(sharedSettings: _*).aggregate(child1, child2)
lazy val sharedCode = project.settings(sharedSettings: _*)
val child1Settings = sharedSettings ++ Seq(unmanagedSourceDirectories in Compile <++= (unmanagedSourceDirectories in sharedCode) in Compile)
val child2Settings = sharedSettings ++ Seq(unmanagedSourceDirectories in Compile <++= (unmanagedSourceDirectories in sharedCode) in Compile)
lazy val child1 = project.settings(child1Settings: _*)
lazy val child2 = project.settings(child2Settings: _*)
I can run sbt publish okay, and it creates the directory com/example/test-lib/XXX in the repo.
In my test program, I have the following:
scalaVersion := "2.11.0",
resolvers += "Artifactory Realm" at "http://localhost:8081/artifactory/libs-snapshot-local",
libraryDependencies += "com.example" %% "test-lib" % "0.1-SNAPSHOT"
When the test program attempts to compile, it cannot resolve com.example, because of the following:
[warn] ==== Artifactory Realm: tried
[warn] http://localhost:8081/artifactory/libs-snapshot-local/com/example/test-lib_2.11/0.1-SNAPSHOT/test-lib_2.11-0.1-SNAPSHOT.pom
Looking at the repository directory itself, I am getting an additional timestamp on my pom files:
test-lib_2.11-0.1-20140510.183027-1.pom 10-May-2014 19:30 793 bytes
test-lib_2.11-0.1-20140510.183027-2.pom 10-May-2014 19:30 793 bytes
...
test-lib_2.11-0.1-20140510.183121-9.pom 10-May-2014 19:31 793 bytes
maven-metadata.xml in the directory is referencing these okay, sbt is looking directly for a pom file without a timestamp and cannot find it. The pom files contain the correct information.
What am I doing wrong?
The issue was not with my sbt configuration after all, but with my repository server.
I'm using Artifactory, and the snapshots repository was configured to use "unique snapshots" by default. The filenames of these snapshots are modified as they are published to include a timestamp, which sbt 13.x doesn't seem to understand.
After changing the repository's "Maven Snapshot Version Behaviour" from "Unique" to "Nonunique", everything started to work.
actually, the inconsistency of timestamp & build number suffix in maven-metadata.xml and jar/pom files genereated by sbt publish lead to such error.
with the following plugin sbt-maven-resolver during deployment procedure, the suffix will be kept same, looks like:
currently, adding this plugin on the deployment side (once the timestamp & build suffix are same, both sbt/maven can find the snapshots):
in plugins.sbt
addSbtPlugin("org.scala-sbt" % "sbt-maven-resolver" % "0.1.0")
hope to solve your case.