Setting a third-party plugin setting in sbt AutoPlugin - scala

I have an AutoPlugin which aggregates several third-party plugins and customizes their settings for our company. For most of the plugins, this works just fine by putting them in the projectSettings:
override lazy val projectSettings = Seq( somePluginSetting := "whatever" )
I tried to do this for ScalaStyle as well:
import org.scalastyle.sbt.ScalastylePlugin.scalastyleConfigUrl
override lazy val projectSettings = Seq(
scalastyleConfigUrl := Some(url("http://git.repo/scalastyle-config.xml"))
)
This setting is never visible in projects using my plugin, instead sbt uses the plugin-provided default value:
> inspect scalastyleConfigUrl
[info] Setting: scala.Option[java.net.URL] = None
[info] Description:
[info] Scalastyle configuration file as a URL
[info] Provided by:
[info] {file:/Users/kaeser/Documents/workspace/ci-test-project/}root/*:scalastyleConfigUrl
[info] Defined at:
[info] (org.scalastyle.sbt.ScalastylePlugin) Plugin.scala:101
[info] Delegates:
[info] *:scalastyleConfigUrl
[info] {.}/*:scalastyleConfigUrl
[info] */*:scalastyleConfigUrl
[info] Related:
[info] test:scalastyleConfigUrl
When I put the setting into build.sbt directly, it works as expected.
I made a simple example sbt plugin that shows the problem: https://github.com/jastice/sbt-customsettings
What might the issue be?

This problem is most likely caused by the order in which settings are applied. If your plugin and the plugin you are depending on are both autoplugins, the requires value determines the order in which project settings are included.
Scalastyle still uses the old plugin format. It also does not follow the best practices. It should not set projectSettings as that makes it difficult to disable it in multi project builds. And it also prevents you from easily extending it from your custom plugin. I am not sure if the order in which project settings are applied is defined, or is determined by the order in which the plugins are loaded.
The easiest fix would be to make Scalastyle an AutoPlugin and depend on it using the requires value. Otherwise it's probably quite tricky to find out what determines the order.

Related

Exclude dependency from project in multi-module SBT project [duplicate]

In Build.scala I have a dependency between projects:
val coreLib = Projects.coreLib()
val consoleApp = Projects.consoleApp().dependsOn(coreLib)
val androidApp = Projects.androidProject().dependsOn(coreLib/*, exclusions = xpp */)
Core library project defines a library in its libraryDependencies (XPP parser), which I want to exclude in androidApp, since Android framework have its own XPP implementation out of the box.
How can I exclude XPP library from transitive dependencies of coreLib in androidApp project?
EDIT:
According to my research exclusion is possible ONLY to ModuleID which is used in conjunction with libraryDependency. Meanwhile dependsOn puts all transitive dependencies to classpath, there is no way in api to exclude some transitive dependencies of this project, you dependsOn
DETAILS:
I'm running sbt 0.13.5 currently.
libraryDependencies of commonLib as well as it various settings supplied in build.sbt so that this project could be reused as standalone, and because it feels right and natural way of supplying settings in sbt.
This appears to work for me:
val someApp = project.settings(
libraryDependencies += "junit" % "junit" % "4.11"
)
val androidApp = project.dependsOn(someApp).settings(
projectDependencies := {
Seq(
(projectID in someApp).value.exclude("junit", "junit")
)
}
)
What the projectDepenendencies is doing is what sbt, by default, attempts to do. It converts any inter-project dependencies into ModuleIDs which Ivy will use during resolution. Because the Project API has no way to specify excludes currently, we bypass this automatic layer and manually declare the Ivy dependency as well.
Result:
> show someApp/update
...
[info] Update report:
...
[info] compile:
[info] org.scala-lang:scala-library:2.10.4 (): (Artifact(scala-library,jar,jar,None,List(),None,Map()),/home/jsuereth/.sbt/boot/scala-2.10.4/lib/scala-library.jar)
[info] junit:junit:4.11: (Artifact(junit,jar,jar,None,ArraySeq(master),None,Map()),/home/jsuereth/.ivy2/cache/junit/junit/jars/junit-4.11.jar)
[info] org.hamcrest:hamcrest-core:1.3: (Artifact(hamcrest-core,jar,jar,None,ArraySeq(master),None,Map()),/home/jsuereth/.ivy2/cache/org.hamcrest/hamcrest-core/jars/hamcrest-core-1.3.jar)
...
And the dependent project with junit/hamcrest excluded:
> show androidApp/update
...
[info] Update report:
...
[info] compile:
[info] org.scala-lang:scala-library:2.10.4 (): (Artifact(scala-library,jar,jar,None,List(),None,Map()),/home/jsuereth/.sbt/boot/scala-2.10.4/lib/scala-library.jar)
[info] someapp:someapp_2.10:0.1-SNAPSHOT:
...

How to use Quasar with Scala under sbt?

I wish to use Quasar in my SBT project. Since Scala is not yet supported the only viable option left is to have SBT compile some java classes that use of Quasar.
I tried putting
javaOptions += "-javaagent:PATH_TO_JAR/quasar-core-0.5.0.jar"
and
fork := true
as I read that for using e.g. JRebel one must insert both these statements into build.sbt
But it does not seem to work either as using a Quasarish class (QuasarExample) yields:
[error] IllegalArgumentException: : Fiber class HelloWorldSpec$$anonfun$1$$anonfun$apply$3$$anon$1 has not been instrumented. (Fiber.java:151)
[error] co.paralleluniverse.fibers.Fiber.<init>(Fiber.java:151)
[error] co.paralleluniverse.fibers.Fiber.<init>(Fiber.java:171)
[error] co.paralleluniverse.fibers.Fiber.<init>(Fiber.java:448)
A piece of code that's expected to be running without errors after successful instrumentation:
new Fiber<Integer>() {
#Override
protected Integer run() throws SuspendExecution, InterruptedException {
return 0;
}
}.start();
See also this repository for a starter.
As per the comment from #mjaskowski, Dou you plan to instrument bytecode produced by Scala compiler?, Scala is not a supported language yet.
Short answer is: absolutely. Longer answer is, yes, but not very soon.
Scala is a very (very, very, very, very) complex language (oh my god,
it's so incredibly complex!), and it would take a long time to test
Quasar with the many (many-many-many) Scala features. Given the
relatively small number of Scala developers, and the heavy integration
costs, this may take some time. We do, however support Clojure (much
simpler integration), and will soon probably (or maybe we already do)
support Kotlin (trivial integration).
Follow along to see the possible ways to have the javaagent set up in sbt.
This is my first encounter with Quasar so the steps are really basic however they should give you a head start.
Running Quasar's javaagent in JVM alone
It's only with the following command to be able to run Quasar's javaagent without any Scala/sbt's jars.
java -cp
/Users/jacek/.ivy2/cache/org.ow2.asm/asm-util/jars/asm-util-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm-commons/jars/asm-commons-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm/jars/asm-5.0.1.jar -javaagent:/Users/jacek/.ivy2/cache/co.paralleluniverse/quasar-core/jars/quasar-core-0.5.0.jar
-help
It appears it's not self-contained and needs additional jars on the CLASSPATH.
Running Quasar's javaagent with scala
The following command makes scala and Quasar's javaagent happy.
scala -debug -usebootcp -toolcp
/Users/jacek/.ivy2/cache/org.ow2.asm/asm-tree/jars/asm-tree-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm-util/jars/asm-util-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm-commons/jars/asm-commons-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm/jars/asm-5.0.1.jar:/Users/jacek/.ivy2/cache/org.ow2.asm/asm-analysis/jars/asm-analysis-5.0.1.jar
-J-javaagent:/Users/jacek/.ivy2/cache/co.paralleluniverse/quasar-core/jars/quasar-core-0.5.0.jar
Initial attempts to run Quasar with sbt
Add the necessary dependencies of Quasar in build.sbt:
val quasarDeps = Seq(
"quasar-core",
"quasar-actors",
"quasar-galaxy"
)
libraryDependencies := quasarDeps.map("co.paralleluniverse" % _ % "0.5.0")
It boils down to augmenting libraryDependencies with necessary jars. I chose all available.
I checked in Scala console that the libraries are available.
➜ quasar-sbt xsbt
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to quasar-sbt (in build file:/Users/jacek/sandbox/quasar-sbt/)
> console
Welcome to Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_60).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import co.paralleluniverse.fibers._
import co.paralleluniverse.fibers._
scala> Fiber.DEFAULT_STACK_SIZE
res0: Int = 32
You will also have to add the java agent. Add the following to build.sbt:
// FIXME the path to quasar-core should be simpler
javaOptions in Test += "-javaagent:/Users/jacek/.ivy2/cache/co.paralleluniverse/quasar-core/jars/quasar-core-0.5.0.jar"
fork in Test := true
// only needed for Specs2 so I could test the test setup
libraryDependencies += "org.specs2" %% "specs2" % "2.3.13" % Test
scalacOptions in Test ++= Seq("-Yrangepos")
reload the build changes.
> reload
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Set current project to quasar-sbt (in build file:/Users/jacek/sandbox/quasar-sbt/)
Write a test to make sure all's set up properly. I used the HelloWorldSpec from [Specs2][2] with some changes:
import org.specs2.mutable._
import co.paralleluniverse.fibers._
class HelloWorldSpec extends Specification {
"Quasar" should {
"Fiber.DEFAULT_STACK_SIZE defaults to 32" in {
Fiber.DEFAULT_STACK_SIZE === 32
}
}
}
It's not a very extensive test, so tweak it for your needs. Save the file under src/test/scala.
Execute test.
> test
objc[27427]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
[info] HelloWorldSpec
[info]
[info] Quasar should
[info] + Fiber.DEFAULT_STACK_SIZE defaults to 32
[info]
[info] Total for specification HelloWorldSpec
[info] Finished in 40 ms
[info] 1 example, 0 failure, 0 error
[info] Passed: Total 1, Failed 0, Errors 0, Passed 1
[success] Total time: 4 s, completed Jul 13, 2014 2:04:13 PM
It works!

Exclude test dependency resolution from `sbt compile`

When running sbt compile, dependencies marked as test are still resolved even though they are not later included later in compilation. It seems like this should only happen during the test:compile task. Is there a way to exclude test dependencies from being resolved and downloaded during the compile task?
Here is an example with the org.mockito#mockito-all dependency. I have it declared as test-only:
"org.mockito" % "mockito-all" % "1.9.0" % "test"
However, when (clearing it from my local Ivy cache and) running sbt compile, it gets needlessly downloaded:
$ sbt compile
[info] Loading global plugins from /Users/rbrainard/.sbt/plugins
[info] Loading project definition from /Users/rbrainard/Development/spitball/project
[info] Set current project to spitball (in build file:/Users/rbrainard/Development/spitball/)
[info] Updating {file:/Users/rbrainard/Development/spitball/}spitball...
[info] Resolving org.mockito#mockito-all;1.9.0 ...
[info] downloading http://repo1.maven.org/maven2/org/mockito/mockito-all/1.9.0/mockito-all-1.9.0.jar ...
[info] [SUCCESSFUL ] org.mockito#mockito-all;1.9.0!mockito-all.jar (2075ms)
[info] Done updating.
[success] Total time: 7 s, completed May 28, 2014 4:51:20 PM
In sbt the update task resolves all dependencies for all configurations. Sbt makes use of Ivy, which promotes a very interesting "configuration" aspect to be able to separately resolve disparate classpaths at the same time.
Sbt is not only resolving your test classpath, but also runtime, the scala-tools (compiler, scaladoc, repl) and more.
Please read: https://ant.apache.org/ivy/history/latest-milestone/terminology.html for more information on the design of Ivy, which is why sbt attempts to do all resolution at once for all configurations.

Make one sbt config depend on another

The sbt documentation shows example of how to declare dependency only between projects. But I'm positive that there are ways to declare one config be dependent on another, just like the Test configuration uses classpath from the Compile configuration.
How can I declare my own configuration so that it would depend on the Compile config generated classpath?
I take a more close look to suggested solution and bunch of question arose again. So I reopen the question
I can not deduce sbt behavior solely from the delegate relation between Test and Compile config.
The source directories turn out to be completely different for Test and Compile config despite being delegated.
> show test:unmanagedSourceDirectories
[info] List(./src/test/scala, ./src/test/java)
> show test:scalaSource
[info] ./src/test/scala
> show test:javaSource
[info] ./src/test/java
> show compile:unmanagedSourceDirectories
[info] List(./src/main/scala, ./src/main/java)
> show compile:scalaSource
[info] ./src/main/scala
> show compile:javaSource
[info] ./src/main/java
And other significant keys such as unmanagementClasspath and fullClasspath are not SettingsKeys that may be naturally stacked with delegating. They are full-fledged TaskKeys that stores complex procedure for generating class-paths behind them.
So, the question is still actual: How can I mimic exporting classes from Compile to Test config for my custom defined config? And there is closely related optional question: how this is actually done for aforementioned pre-defined configs?
You can make one configuration extend another. You do that by using extend method.
lazy val MyConfig = config("myConfig") extend(Compile)
lazy val root = project.in(file(".")).
configs(MyConfig).
settings(inConfig(MyConfig)(Defaults.compileSettings ++ Defaults.compileInputsSettings): _*)
Extend will delegate to Compile in this case, for settings which are undefined in the MyConfig configuration.
You can check it by running SBT and executing for example show myConfig:managedClasspath, the output should be exactly the same as for show compile:managedClasspath.
If you inspect your new configuration's managedClasspath you'll see that it delegates to the compile.
[info] Delegates:
[info] myConfig:managedClasspath
[info] compile:managedClasspath
[info] *:managedClasspath
[info] {.}/myConfig:managedClasspath
[info] {.}/compile:managedClasspath
[info] {.}/*:managedClasspath
[info] */myConfig:managedClasspath
[info] */compile:managedClasspath
[info] */*:managedClasspath
As I've stated above, SBT will only delegate to the setting if it's not defined in the given configuration.
For example, if you do not define any specific compiler options for myConfig the settings will be taken from compile.
> show compile:scalacOptions
[info] List()
> show myConfig:scalacOptions
[info] List()
Changing setting in compile configuration will have an effect on myConfig:
> set scalacOptions in Compile += "-Xexperimental"
> show compile:scalacOptions
[info] List(-Xexperimental)
> show myConfig:scalacOptions
[info] List(-Xexperimental)
Overriding the setting in myConfig will make SBT to use the setting defined in that configuration, while Compile will have its own value:
> set scalacOptions in MyConfig := Seq("-Xcheck-null")
> show compile:scalacOptions
[info] List(-Xexperimental)
> show myConfig:scalacOptions
[info] List(-Xcheck-null)
Note the delegation is one way. Change to the MyConfig has no influence on the Compile configuration.
You can check the documentation for details.

how to set main class in SBT 0.13 project

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.