How to publish an artifact with pom-packaging in SBT? - sbt

I have a multi-project build in SBT where some projects should aggregate dependencies and contain no code. So then clients could depend on these projects as a single dependency instead of directly depending on all of their aggregated dependencies. With Maven, this is a common pattern, e.g. when using Spring Boot.
In SBT, I figured I can suppress the generation of the empty artifacts by adding this setting to these projects:
packagedArtifacts := Classpaths.packaged(Seq(makePom)).value
However, the makePom task writes <packaging>jar</packaging> in the generated POM. But now that there is no JAR anymore, this should read <packaging>pom</packaging> instead.
How can I do this?

This question is a bit old, but I just came across the same issue and found a solution. The original answer does point to the right page where this info can be found, but here is an example. It uses the pomPostProcess setting to transform the generated POM right before it is written to disk. Essentially, we loop over all the XML nodes, looking for the element we care about and then rewrite it.
import scala.xml.{Node => XmlNode, NodeSeq => XmlNodeSeq, _}
import scala.xml.transform._
pomPostProcess := { node: XmlNode =>
val rule = new RewriteRule {
override def transform(n: XmlNode): XmlNodeSeq = n match {
case e: Elem if e != null && e.label == "packaging" =>
<packaging>pom</packaging>
case _ => n
}
}
new RuleTransformer(rule).transform(node).head
},

Maybe you could modify the result pom as described here: Modifying the generated POM

You can disable publishing the default artifacts of JAR, sources, and docs, then opt in explicitly to publishing the POM. sbt produces and publishes a POM only, with <packaging>pom</packaging>.
// This project has no sources, I want <packaging>pom</pom> with dependencies
lazy val bundle = project
.dependsOn(moduleA, moduleB)
.settings(
publishArtifact := false, // Disable jar, sources, docs
publishArtifact in makePom := true,
)
lazy val moduleA = project
lazy val moduleB = project
lazy val moduleC = project
Run sbt bundle/publishM2 to verify the POM in ~/.m2/repository.
I dare say this is almost intuitive, a rare moment of pleasant surprise with sbt 😅
I confirmed this with current sbt 1.3.9, and 1.0.1, the oldest launcher I happen to have installed on my machine.
The Artifacts page in the reference docs may be helpful, perhaps this trick should be added there.

Related

ivy.xml based sbt publish

There are 2 questions,
I defined publishTo with a resolver "abc", which is not in the external ivysettings.xml. When I do the publish, sbt complains resolver "abc" is undefined.
I defined an artifact, which is a zipped package, to be published, and the corresponding settings are as follows,
val ZIP = Configurations.config("app")
val artifact = SettingKey[Artifact]("artifact")
val pack = TaskKey[File]("pack")
val settings = Seq(artifact := Artifact(name.value, "zip", "zip", Some("app"), List(ZIP), None)) ++ addArtifact(artifact, pack).settings
It works pretty well when dependencies are managed by sbt itself, but totally cannot work (meaning the local publish just ignores publish of this artifact) if they are managed by ivy. How can I get over these?
Seems like the custom artifact settings does not work only if they are imported with an auto plugin, is it a bug or am I missing something?
thanks to this post:
How can a default task be overridden from an AutoPlugin?
so the artifacts settings must be introduced after sbt's own plugins are imported, otherwise it'd be overwritten.

How to stop xsbt from reloading webapp on resources change

We are using sbt with xsbt-web-plugin to develop our liftweb app. In our project build we have several subprojects and we use dependencies of a Project to share some stuff between all the subprojects.
object ProjectBuild extends Build {
//...
lazy val standalone = Project(
id = "standalone",
base = file("standalone"),
settings = Seq(...),
dependencies = Seq(core) // please notice this
)
lazy val core = Project(
id = "core",
base = file("core"),
settings = Seq(...)
}
// ...
}
To ease the development we use 'project standalone' '~;container:start; container:reload /' command automatically recompile changed files.
We decided to serve some common assets from shared core project as well. This works fine with lift. But what we faced when added our files to core/src/main/resources/toserve folder, is that any change to any javascript or css file causes application to restart jetty. This is annoying since such reload takes lots of resources.
So I started investigating on how to prevent this, even found someone mentioning watchSources sbt task that scans for changed files.
But adding this code as a watchSources modification (event that println prints all the files) does not prevent from reloading webapp each time I change assets located in core resources folder.
lazy val core = Project(
id = "core",
base = file("core"),
settings = Seq(
// ...
// here I added some tuning of watchSources
watchSources ~= { (ws: Seq[File]) => ws filterNot { path =>
println(path.getAbsolutePath)
path.getAbsolutePath.endsWith(".js")
} }
)
I also tried adding excludeFilter to unmanagedSorces, unmanagedResorces but with no luck.
I'm not an sbt expert and such modification of settings looks more like a magic for me (rather then a usual code). Also such tuning seem to be uncovered by documentation =(
Can anyone please help me to prevent sbt from reloading webapp on each asset file change?
Thanks a lot!
You're on the right track by using watchSources, but you'll also need to exclude the resources directory itself:
watchSources ~= { (ws: Seq[File]) =>
ws filterNot { path =>
path.getName.endsWith(".js") || path.getName == ("resources")
}
}
Can you switch from using "resources" folder to using "webapp" folder? That will also free you from restarts. Here's a demo project for Lift (that uses "webapp"):
https://github.com/lift/lift_26_sbt/
For example, the "basic" template:
https://github.com/lift/lift_26_sbt/tree/master/scala_211/lift_basic/src/main/webapp

SBT hangs resolving dependencies

We have an SBT 0.13.0 multi-project build with 17 projects: 1 leaf project, 15 modules that depend on the leaf (but not each other), and 1 aggregator that depends on the 15 modules.
Here's a very rough idea of what the Build.scala file looks like:
val deps: Seq[Setting[_]] = Seq(libraryDependencies ++= Seq(
"com.foo" % "foo" % "1.0.0",
"com.bar" % "bar" % "1.0.0"
))
val leaf = Project("leaf").settings(deps:_*)
val module1 = Project("module1").dependsOn(leaf).settings(deps:_*)
val module2 = Project("module2").dependsOn(leaf).settings(deps:_*)
...
val module15 = Project("module15").dependsOn(leaf).settings(deps:_*)
val aggregator = Project("aggregator)".dependsOn(
module1,
module2,
...
module15
).settings(deps:_*)
All of these projects list exactly the same set of external dependencies as libraryDependencies. For some reason, when we run the update command in the aggregator, it takes on the order of a minute per project (~15 minutes total!), even though there is no single new dependency to resolve or download.
Worse yet, we recently added one more dependency and now the update command causes SBT to swell up to ~5GB of memory and sometimes hang completely during resolution. How do we debug this?
We tried YourKit to profile it and, it may be a read herring, but so far, the only thing we see is some sbt.MultiLogger class spending a ton of time in a BufferedOutputStream.flush call.
If some of your external dependiencies are actually your own libraries pushed to a local repository and their version is set to "latest" then this hanging is expected. The reason is that ivy tries all repositories for all dependencies when "latest" version is required. Since your libraries are not pushed to public repositories then checking for them on public repositories ends in timeout (it is an ivy issue apparently).
I tried to replicate your setup and created an sbt project with leaf, 15 modules, aggregator and a few external dependencies. It all resolves quite quickly. You can check it out at
https://github.com/darkocerdic/sbt-multiproject-resolving

Adding /etc/<application> to the classpath in sbt-native-packager for debian:package-bin

So I'm using the packageArchetype.java_server and setup my mappings so the files from "src/main/resources" go into my "/etc/" folder in the debian package. I'm using "sbt debian:package-bin" to create the package
The trouble is when I use "sbt run" it picks up the src/main/resources from the classpath. What's the right way to get the sbt-native-packager to give /etc/ as a resource classpath for my configuration and logging files?
plugins.sbt:
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.0-M2")
build.sbt
...
packageArchetype.java_server
packageDescription := "Some Description"
packageSummary := "My App Daemon"
maintainer := "Me<me#example.org>"
mappings in Universal ++= Seq(
file("src/main/resources/application.conf") -> "conf/application.conf",
file("src/main/resources/logback.xml") -> "conf/logback.xml"
)
....
I took a slightly different approach. Since sbt-native-packager keeps those two files (application.conf and logback.xml) in my package distribution jar file, I really just wanted a way to overwrite (or merge) these files from /etc. I kept the two mappings above and just added the following:
src/main/templates/etc-default:
-Dmyapplication.config=/etc/${{app_name}}/application.conf
-Dlogback.configurationFile=/etc/${{app_name}}/logback.xml
Then within my code (using Typesafe Config Libraries):
lazy val baseConfig = ConfigFactory.load //defaults from src/resources
//For use in Debain packaging script. (see etc-default)
val systemConfig = Option(System.getProperty("myapplication.config")) match {
case Some(cfile) => ConfigFactory.parseFile(new File(cfile)).withFallback(baseConfig)
case None => baseConfig
}
And of course -Dlogback.configuration is a system propety used by Logback.

Defining plugin dependency between subprojects in SBT?

EDIT:
Since I put up the bounty, I thought I should restate the question
How can a SBT project P, with two sub-projects A and B, set up B to have a plugin dependency on A, which is a SBT plugin?
Giving P a plugin dependency on A does not work, since A depends on other things in P, which results in a circular dependency graph
It has to be a plugin dependency, for A is a plugin needed to run Bs test suite.
dependsOn doesn't work, because, well, it has to be a plugin dependency
I'd like to know either of
How to do this, or
Why this is impossible, and what the next best alternatives are.
EDIT: clarified that it's a plugin-dependency, since build-dependency is ambiguous
When you have a multi-project build configuration with "project P and two sub-projects A and B" it boils down to the following configuration:
build.sbt
lazy val A, B = project
As per design, "If a project is not defined for the root directory in the build, sbt creates a default one that aggregates all other projects in the build." It means that you will have an implicit root project, say P (but the name is arbitrary):
[plugin-project-and-another]> projects
[info] In file:/Users/jacek/sandbox/so/plugin-project-and-another/
[info] A
[info] B
[info] * plugin-project-and-another
That gives us the expected project structure. On to defining plugin dependency between B and A.
The only way to define a plugin in a SBT project is to use project directory that's the plugins project's build definition - "A plugin definition is a project in <main-project>/project/." It means that the only way to define a plugin dependency on the project A is to use the following:
project/plugins.sbt
addSbtPlugin("org.example" % "example-plugin" % "1.0")
lazy val plugins = project in file(".") dependsOn(file("../A"))
In this build configuration, the plugins project depends on another SBT project that happens to be our A that's in turn a plugin project.
A/build.sbt
// http://www.scala-sbt.org/release/docs/Extending/Plugins.html#example-plugin
sbtPlugin := true
name := "example-plugin"
organization := "org.example"
version := "1.0"
A/MyPlugin.scala
import sbt._
object MyPlugin extends Plugin
{
// configuration points, like the built in `version`, `libraryDependencies`, or `compile`
// by implementing Plugin, these are automatically imported in a user's `build.sbt`
val newTask = taskKey[Unit]("A new task.")
val newSetting = settingKey[String]("A new setting.")
// a group of settings ready to be added to a Project
// to automatically add them, do
val newSettings = Seq(
newSetting := "Hello from plugin",
newTask := println(newSetting.value)
)
// alternatively, by overriding `settings`, they could be automatically added to a Project
// override val settings = Seq(...)
}
The two files - build.sbt and MyPlugin.scala in the directory A - make up the plugin project.
The only missing piece is to define the plugin A's settings for the project B.
B/build.sbt
MyPlugin.newSettings
That's pretty much it what you can do in SBT. If you want to have multi-project build configuration and have a plugin dependency between (sub)projects, you don't have much choice other than what described above.
With that said, let's see if the plugin from the project A is accessible.
[plugin-project-and-another]> newTask
Hello from plugin
[success] Total time: 0 s, completed Feb 13, 2014 2:29:31 AM
[plugin-project-and-another]> B/newTask
Hello from plugin
[success] Total time: 0 s, completed Feb 13, 2014 2:29:36 AM
[plugin-project-and-another]> A/newTask
[error] No such setting/task
[error] A/newTask
[error] ^
As you may have noticed, newTask (that comes from the plugin from the project A) is available in the (default) root project and the project B, but not in A.
As Jacek said, it cannot be done as I would like, as a subproject cannot have a SBT plugin that the root project does not. On the other hand, this discussion on the mailing list contains several alternatives, and would no doubt be useful to anyone who comes across this question in the future.
EDIT: Well, in the end the alternatives mentioned (sbt scripted, etc) were hard and clunky to use. My final solution was to just have a separate project (not subproject) inside the repo that depends on the original project via it's ivy coordinates, and using bash to publishLocal the first project, going into the second project and running its tests
sbt publishLocal; cd test; sbt test; cd ..
I always thought the point of something like SBT was to avoid doing this kind of bash gymnastics, but desperate times call for desperate measures...
This answer may include the solution https://stackoverflow.com/a/12754868/3189923 .
From that link, in short, set exportJars := true and to obtain jar file paths for a (sub)project exportedProducts in Compile.
Leaving the facts about plugins by side, you have a parent project P with sub-projects A and B. And then you state that A depends on P. But P is a aggregate of A and B and hence depends on A. So you already have a circular dependency between A and P. This can never work.
You have to split P in two parts: The part where A depends on (let's call this part A') and the rest (let's call this P_rest). Then you throw away P and make a new project P_rest consisting of A', A and B. And A depends on A'.

Resources