I have a two sub-projects and top level project which agreegates them.
I can successfully release all of them but only version on top level project is changed and sub-projects are released with the version defined in their directory which unfortunately is not changed during release.
Root
|
-SubA
| |- version.sbt -> version in SubA := "0.0.1-SNAPSHOT"
|
-SubB
| |- version.sbt -> version in SubB := "0.0.4-SNAPSHOT"
|- version.sbt -> version in ThisBuild := "0.1.0-SNAPSHOT"
After release I would like to have:
Root released as 0.1.0 (although I don't care about the root at all)
SubA released as 0.0.1
SubB released as 0.0.4
and each version is incremeted for example in SubA/version.sbt -> 0.0.2-SNAPSHOT
How can I do that using sbt 0.13 and sbt-release plugin?
You need to override the default location of the version.sbt file in each build.sbt of your submodule:
import ReleaseKeys._
organization := "com.organization"
name := "moduleName"
version := (version in ThisBuild).value
scalaVersion := "2.11.6"
releaseSettings
versionFile := file(name.value + "/version.sbt")
By default, version.sbt is located at the ROOT folder by sbt-release.
Make a separate class/object and define a commonSettings lazy val, and set the version := {your_docker_version) there (you can override this value in different ways e.g. via System.property etc.
Then use this commonSettings in all of your Modules.
Related
I'd like to create an SBT project with inheritance and shared dependencies.
With Maven's POM files, there is the idea of Project Inheritance where you can set a parent project. I'd like to do the same thing with SBT.
The xchange-stream library uses Maven's Project Inheritance to resolve subproject dependencies when compiled from the parent project.
Here is my idea of what the file structure would look like:
sbt-project/
project/
dependencies.scala # Contains dependencies common to all projects
build.sbt # Contains definition of parent project with references
# to subprojects
subproject1/
build.sbt # Contains `subproject3` as a dependency
subproject2/
build.sbt # Contains `subproject3` as a dependency
subproject3/
build.sbt # Is a dependency for `subproject1` and `subproject2`
Where project1 and project2 can include project3 in their dependencies lists like this:
libraryDependencies ++= "tld.organization" % "project3" % "1.0.0"
Such that when subproject1 or subproject2 are compiled by invoking sbt compile from within their subdirectories, or when the parent: sbt-project is compiled from the main sbt-project directory, then subproject3 will be compiled and published locally with SBT, or otherwise be made available to the projects that need it.
Also, how would shared dependencies be specified in sbt-project/build.sbt or anywhere in the sbt-project/project directory, such that they are useable within subproject1 and subproject2, when invoking sbt compile within those subdirectories?
The following examples don't help answer either of the above points:
jbruggem/sbt-multiproject-example:
Uses recursive build.sbt files, but doesn't share dependencies among child projects.
Defining Multi-project Builds with sbt: pbassiner/sbt-multi-project-example:
Uses a single build.sbt file for the projects in their subdirectories.
sachabarber/SBT_MultiProject_Demo:
Uses a single build.sbt file.
Such that when subproject1 or subproject2 are compiled by invoking sbt compile from within their subdirectories...
Maybe Maven is meant to be used together with the shell environment and cd command, but that's not how sbt works at least as of sbt 1.x in 2019.
The sbt way is to use sbt as an interactive shell, and start it at the top level. You can then either invoke compilation as subproject1/compile, or switch into it using project subproject1, and call compile in there.
house plugin
A feature similar to parent POM would be achieved by creating a custom plugin.
package com.example
import sbt._
import Keys._
object FooProjectPlugin extends AutoPlugin {
override def requires = plugins.JvmPlugin
val commonsIo = "commons-io" % "commons-io" % "2.6"
override def buildSettings: Seq[Def.Setting[_]] = Seq(
organization := "com.example"
)
override def projectSettings: Seq[Def.Setting[_]] = Seq(
libraryDependencies += commonsIo
)
}
sbt-sriracha
It's not exactly what you are asking for, but I have an experimental plugin that allows you to switch between source dependency and binary dependency. See hot source dependencies using sbt-sriracha.
Using that you could create three individual sbt builds for project1, project2, and project3, all located inside $HOME/workspace directory.
ThisBuild / scalaVersion := "2.12.8"
ThisBuild / version := "0.1.1-SNAPSHOT"
lazy val project3Ref = ProjectRef(workspaceDirectory / "project3", "project3")
lazy val project3Lib = "tld.organization" %% "project3" % "0.1.0"
lazy val project1 = (project in file("."))
.enablePlugins(FooProjectPlugin)
.sourceDependency(project3Ref, project3Lib)
.settings(
name := "project1"
)
With this setup, you can launch sbt -Dsbt.sourcemode=true and it will pick up project3 as a subproject.
You can use Mecha super-repo concept. Take a look on the setup and docs here: https://github.com/storm-enroute/mecha
The basic idea is that you can combine dependent sbt projects (with their own build.sbt) under single root super-repo sbt project:
/root
/project/plugins.sbt
repos.conf
/project1
/src/..
/project/plugins.sbt
build.sbt
/project2
/src/..
/project/plugins.sbt
build.sbt
Please, note that there is no build.sbt in the root folder!
Instead there is repos.conf file. It contains definition of the sub-repos and looks like the folowing:
root {
dir = "."
origin = ""
mirrors = []
}
project1 {
dir = "project1"
origin = "git#github.com:some_user/project1.git"
mirrors = []
}
project2 {
dir = "project2"
origin = "git#github.com:some_user/project2.git"
mirrors = []
}
Then you can specify the Inter-Project, source-level Dependencies within individual projects.
There are two approaches:
dependencies.conf file
or in the build source code
For more details, please, see the docs
I'm attempting to use the sbt-aspectj plugin with the sbt native packager and am running into an issue where the associated -javaagent path to the aspectj load time weaver jar references an ivy cache location rather than something packaged.
That is, after running sbt stage, executing the staged application via bash -x target/universal/stage/bin/myapp/ results in this javaagent:
exec java -javaagent:/home/myuser/.ivy2/cache/org.aspectj/aspectjweaver/jars/aspectjweaver-1.8.10.jar -cp /home/myuser/myproject/target/universal/stage/lib/org.aspectj.aspectjweaver-1.8.10.jar:/home/myuser/myproject/target/universal/stage/lib/otherlibs.jar myorg.MyMainApp args
My target platform is Heroku where the artifacts are built before being effectively 'pushed' out to individual 'dynos' (very analogous to a docker setup). The issue here is that the resulting -javaagent path was valid on the machine in which the 'staged' deployable was built, but will not exist where it's ultimately run.
How can one configure the sbt-aspectj plugin to reference a packaged lib rather than one from the ivy cache?
Current configuration:
project/plugins.sbt:
addSbtPlugin("com.typesafe.sbt" % "sbt-aspectj" % "0.10.6")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.1.5")
build.sbt (selected parts):
import com.typesafe.sbt.SbtAspectj._
lazy val root = (project in file(".")).settings(
aspectjSettings,
javaOptions in Runtime ++= { AspectjKeys.weaverOptions in Aspectj }.value,
// see: https://github.com/sbt/sbt-native-packager/issues/598#issuecomment-111584866
javaOptions in Universal ++= { AspectjKeys.weaverOptions in Aspectj }.value
.map { "-J" + _ },
fork in run := true
)
Update
I've tried several approaches including pulling the relevant output for javaOptions from existing mappings, but the result is a cyclical dependency error thrown by sbt.
I have something that technically solves my problem but feels unsatisfactory. As of now, I'm including an aspectjweaver dependency directly and using the sbt-native-packager concept of bashScriptExtraDefines to append an appropriate javaagent:
updated build.sbt:
import com.typesafe.sbt.SbtAspectj._
lazy val root = (project in file(".")).settings(
aspectjSettings,
bashScriptExtraDefines += scriptClasspath.value
.filter(_.contains("aspectjweaver"))
.headOption
.map("addJava -javaagent:${lib_dir}/" + _)
.getOrElse(""),
fork in run := true
)
You can add the following settings in your sbt config:
.settings(
retrieveManaged := true,
libraryDependencies += "org.aspectj" % "aspectjweaver" % aspectJWeaverV)
AspectJ weaver JAR will be copied to ./lib_managed/jars/org.aspectj/aspectjweaver/aspectjweaver-[aspectJWeaverV].jar in your project root.
I actually solved this by using the sbt-javaagent plugin to adding agents to the runtime
I've used sbt-eclipse in the past to successfully import a simple sbt project into eclipse. I'm now trying to leverage the CrossProject mechanism of sbt to use the Scala-JS environment (makes 2 subprojects in sbt--one for Javascript and one for JVM code). The recommendation (see SBT docs link here) is to add the setting 'EclipseKeys.useProjectId := true' in the build.sbt file to support importing (now) 2 projects into one eclipse project. I then give the 'eclipse' command in a running SBT session to create my eclipse project and then launch eclipse and attempt to import this new project. When I do this, the import dialog wizard in eclipse does show me two sub-projects, but when I try to finish the import, eclipse complains that the project already exists and I get two strange looking links in my eclipse project that seem to do nothing.
What is the correct procedure for getting a CrossProject sbt build into eclipse?
Ok, so it seems eclipse did not like that I had only one 'name' for the project that was in the shared settings area of the build.sbt I had this:
lazy val sp = crossProject.in(file(".")).
settings(
version := "0.1",
name := "SJSTut",
scalaVersion := "2.11.7"
).
jvmSettings(
// Add JVM-specific settings here
libraryDependencies ++= Seq(...)
).
jsSettings(
// Add JS-specific settings here
libraryDependencies ++= Seq(...)
)
and what I should have done was this:
lazy val sp = crossProject.in(file(".")).
settings(
version := "0.1",
scalaVersion := "2.11.7"
).
jvmSettings(
// Add JVM-specific settings here
name := "SJSTutJVM",
libraryDependencies ++= Seq(...)
).
jsSettings(
// Add JS-specific settings here
name := "SJSTutJS",
libraryDependencies ++= Seq(...)
)
Note the removal of the 'name' assignment from settings and instead, placements into both the jvmSettings and jsSettings area with uniquely different names.
Now I'm able to pull this into eclipse (as 2 separate projects). If anyone else has a better setup, I'd love to hear about it.
Is it possible to build an sbt plugin in a multi-project setup and use that plugin in some other sub-project of the same multi-project?
For example:
root/
+ mySbtPlugin/
+ myProject/
+ project/
+ plugins.sbt // Uses `mySbtPlugin`
It is not possible since the only way to define plugins for a single or multi-module project is via project (meta)build. I was tricked again to have a solution for you when I set up the sandbox environment with the layout you described.
sbt allows project (meta)project to be in the root directory only. No other project directories are processed and become part of the build definition.
That's why your best (and only) bet is to have the multi-module build for myProject and mySbtPlugin to ease your development, and enable the plugin only for these project(s) you really want to (be careful with auto-plugins, though).
project/plugins.sbt
lazy val root = (project in file(".")) dependsOn sbtNonamePlugin
lazy val sbtNonamePlugin = ProjectRef(file("../sbt-noname"), "sbt-noname")
addSbtPlugin("pl.japila" % "sbt-noname" % "1.0")
build.sbt
lazy val `my-project`, `sbt-noname` = project
sbt-noname/build.sbt
sbtPlugin := true
name := "sbt-noname"
organization := "pl.japila"
version := "1.0"
sbt-noname/src/main/scala/sbtnoname/Plugin.scala
package sbtnoname
import sbt._
import plugins._
object Plugin extends AutoPlugin {
override def trigger = allRequirements
override val projectSettings: Seq[Setting[_]] = inConfig(Test)(baseNonameSettings)
lazy val sayHello = taskKey[Unit]("Say hello")
lazy val baseNonameSettings: Seq[sbt.Def.Setting[_]] = Seq(
sayHello := {
println("I'm the plugin to say hello")
}
)
}
With the files above, run sbt.
> about
[info] This is sbt 0.13.6-SNAPSHOT
[info] The current project is {file:/Users/jacek/sandbox/multi-plugin/}my-project 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.4
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin, sbtnoname.Plugin, com.timushev.sbt.updates.UpdatesPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
> projects
[info] In file:/Users/jacek/sandbox/multi-plugin/
[info] * multi-plugin
[info] my-project
[info] sbt-noname
> plugins
In file:/Users/jacek/sandbox/multi-plugin/
sbt.plugins.IvyPlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.JvmPlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.CorePlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.JUnitXmlReportPlugin: enabled in multi-plugin, sbt-noname, my-project
sbtnoname.Plugin: enabled in multi-plugin, sbt-noname, my-project
> my-project/test:sayHello
I'm the plugin to say hello
[success] Total time: 0 s, completed Jun 15, 2014 3:49:50 PM
I'm trying to use an sbt plugin that I've published in my private mavenrepository
The plugin is configured as following :
val buildSettings = Defaults.defaultSettings ++
Seq (organization := buildOrganization,
scalaVersion := buildScalaVersion,
version := buildVersion,
publishMavenStyle := true,
pomIncludeRepository := { _ => true },
scalacOptions ++= Seq("-deprecation", "-unchecked", "-encoding", "utf8"),
publishTo := Some("External" at "http://xx.yy.net/archiva/repository/external"),
credentials += Credentials(Path.userHome / ".sbt" / ".credentials")
)
With "sbt publish", the plugin is deployed here :
http://xx.yy.net/archiva/repository/external/templemore/sbt-cucumber-parent_2.10/0.8.0/sbt-cucumber-parent_2.10-0.8.0.pom
Then I use my plugin from another SBT app. In my plugins.sbt, I add :
addSbtPlugin("templemore" %% "sbt-cucumber-plugin" % "0.8.0")
But it fails because SBT (or Ivy) is looking at an URL with teh SBT version of the plugin (0.13) inside :
tried
[warn] http://xx.yy.net/archiva/repository/external/templemore/sbt-cucumber-plugin_2.10_0.13/0.8.0/sbt-cucumber-plugin-0.8.0.pom
1) How can I prevent SBT to add its version in the dependency URL?
2) Or, if 1 is not possible, how can I set my SBT plugin configuration to deploy the artifact to archiva with the right URL pattern?
Thanks :)
Based on your comment, you have to publish it with sbt-cucumber-plugin/publish, which will execute publish in a sub-project sbt-cucumber-plugin of the parent project.