Let's say I have a common snippet of statements that I find myself having in many projects. Is there a way to "include" a shared sbt snippet inside another (without writing a plugin)?
e.g.
Snippet (common-mapping.sbt)
mappings in Universal ++= {
for (f <- (baseDirectory.value ** "*-prod.conf").get) yield {
f -> f.getName.replaceAll( """(\w+)-prod\.conf""", "$1.conf")
}
}.toSeq
Project1's build.sbt
...
include("path/to/common-mapping.sbt")
...
Project2's (build.sbt)
...
include("path/to/common-mapping.sbt")
...
Is there a way to do so? or do I need to write a plugin?
p.s. the projects are not necessarily part of the same root project
Plugin is designed to solve this problem, so it's the way to go. Plugins are basically a JAR library that are designed to be used for the builds, and not much else. Also take a look at auto plugins that'll be out in 0.13.5.
Related
When importing a multi-project build.sbt from intelliJ IDEA 2016.1.2 using the native sbt import function, it prompts me which modules I would like to include. The list includes the subprojects/subdirectories in the directory structure I would expect e.g. 'aaa', 'bbb', 'ccc', but then it also offers to import 'aaa-build', 'bbb-build', 'ccc-build', which I have not created.
Ignoring/deselecting the '-build' modules doesn't appear to have any adverse effects.
Can somebody tell me what the purpose of those extra modules is? Just curious.
The directory structure looks something like this:
root/bulid.sbt
root/project
root/aaa
root/aaa/build.sbt
root/aaa/src/main/scala
root/aaa/src/test/scala
root/bbb
root/bbb/build.sbt
...
A newer to scala,if something gets wrong with my answer, I'll improve it.
Those *-build ,they are project subfold in your projects,when you compile these projects with sbt, sbt will read it's peoperties and plugins from peoject fold. It's just like your config which has been compiled.
I want to publish a library, which has some usage examples in runnable classes. When I call sbt run , it finds them and asks me, which of the main classes found I want, and then launches it. That's neat, I'd like this behaviour to stay. But those examples complicate my Android build ( more proguard configs ), so I don't want them in published artefacts.
For now, I totally exclude them, putting this into build.sbt :
excludeFilter in Compile ~= { _ ||
new FileFilter {
def accept(f: File) = f.getPath.containsSlice("/examples/")
} }
then, when I run sbt publish-local, I get jars without examples, but then one can't get the library source and see how it works, with just typing sbt run. How can I exclude examples package only from publishing, but let it still be compiled for local runs?
I'd recommend splitting examples into another subproject instead.
I am using one of sbt plugins that has an object of sbt.Command defined:
val xCommand: Command = Command(xCommandKey)(_ => xParser) { (st, args) => ... }
I need to run it from build.sbt file and have no idea how to do that.
Does anyone know how?
Sbt-files are shorthand for defining configuration. To mix in general scala code you need to add ie. Build.scala into the project directory.
See http://www.scala-sbt.org/0.13/tutorial/Full-Def.html#Relating+build.sbt+to+Build.scala to understand how these files cooperate.
I am trying to define a separate package task without modifying the original task in compile configuration. This new task will package only a subset of classes conforming an API which we need to be able to share with other teams so they can write plugins for our application. So the end result will be two jars, one with the full application and a second one with a subset of the classes.
I approached this problem by creating a different configuration which I called pluginApi and would redefine the packageBin task within this new configuration so it does not change the original definition of packageBin. This idea was taken from here:
How to create custom "package" task to jar up only specific package in SBT?
In my build.stb I have:
lazy val PluginApi = config("pluginApi") extend(Compile) describedAs("Custom plugin api configuration")
lazy val root = project in file(".") overrideConfigs (PluginApi)
This effectively creates my new configuration and I can call
sbt pluginApi:packageBin
Which generates the complete jar in the same way as compile:packageBin would do. I then try to modify the mappings in the new packageBin task with:
mappings in (PluginApi, packageBin) ~= { (ms: Seq[(File, String)]) =>
ms filter { case (file, toPath) =>
toPath.startsWith("some/path/defining/api")
}
}
but this has no effect. I think the reason is because the call to pluginApi:packageBin is delegated to compile:packageBin rather than it being a cloned task.
I can redefine a new packageBin within the new scope like:
packageBin in PluginApi := {
}
However I would have to rewrite all packageBin functionality instead of reusing existing code. Also, in case that rewriting is unavoidable I am not sure how that implementation would be.
Could somebody provide an example about how to achieve this?
You could have it done as follows
lazy val PluginApi = config("pluginApi").extend(Compile)
inConfig(PluginApi)(Defaults.compileSettings) // you have to have standard
mappings in (PluginApi, packageBin) := {
val original = (mappings in (PluginApi, packageBin)).value
original.filter { case (file, toPath) => toPath.startsWith("some/path/defining/api") }
}
unmanagedSourceDirectories in PluginApi := (unmanagedSourceDirectories in Compile).value
Note that, if you keep your sources in src/main/scala you'll have to override unmanagedSourceDirectories in the newly created configuration.
Normally the unmanagedSourceDirectories contains the configuration name. E.g. src/pluginApi/scala or src/pluginApi/java.
I have had similar problems (with more than one jar per project). Our project uses ant - here you can do it, you just will repeat yourself a lot.
However, I have come to the conclusion that this scenario (2 JARs for one project) actually can be simplified by splitting the project - i.e. making 2 modules out of it.
This way, I don't have to "fight" tools which assume project==artifact (like sbt, maybe maven?, IDEA's default setting,...).
As a bonus point the compiler helps me to verify that my dependencies are correct, i.e. that I did not accidentally make my API package depend on the implementation package - when compiling everything together and only splitting classes apart in the JAR step, you do run the risk of getting an invalid dependency in your setup which you would only see when testing, because during compile time everything is compiled together.
This should be very easy, but I am missing something. I apologize for the too-basic question.
I am reorganizing some code. I'd like to get the main package fixed, and then I'll have to modify code in some packages that depend upon the main package. Temporarily, I'd like for those dependent packages not to try to compile in my sbt ~compile world.
I know there exists a setting, excludeFilter in Compile in unmanagedSources, but I don't know what syntax I should use to keep whatever default exclusions are there but to add an new exclusions for (deeply nested) source directories that correspond to dependent packages.
Many thanks for any help!
Here's a working example that excludes anything with any parent directory named foo:
Compile / unmanagedSources / excludeFilter ~= { _ ||
new FileFilter {
def accept(f: File) = f.getPath.containsSlice("/foo/")
} }
(Updated to use sbt 1 style syntax.)