I'm working on an SBT project that has to be built with the options like:
-Xmx2G -Xss256M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
This means that every new developer has to read the readme and assign the options to SBT_OPTS in bash profile or put them in the sbtopts file. Similarly, this has to be configured on Jenkins and this applies to all the projects (so if someone wants to use -XX:+UseG1GC with other projects it becomes an issue). Is it possible to specify the required options in the build file itself? This seems logical to me, as the options are project-specific and without them, you cannot build the project.
Create a .sbtopts file at the root of the build with contents:
-J-Xmx2G
-J-Xss256M
-J-XX:+UseConcMarkSweepGC
-J-XX:+CMSClassUnloadingEnabled
Related
I have a Laravel project with three test directories - Browser, Feature, and Unit.
In Run/Debug configurations I've configured the Feature and the Unit directories to use phpunit.xml while the Browser directory uses phpunit.e2e.xml. I've also created a default configuration for all tests which uses the phpunit.xml.
If I open a class that is in the Feature/Unit directories and run a single test method or the whole class, it picks the default configuration, but when I run a single test method in the Browser directory, it uses phpunit.xml instead of phpunit.e2e.xml.
If I select a directory and run tests, it picks the proper configuration, but when I open a class in the Browser directory, it doesn't
Why doesn't PhpStorm use the configuration of the Browser directory recursively? How can I handle this problem?
As far as I know PhpStorm has never had this functionality and I wouldn't count on them adding it either. It seems way too specific.
What you can do though, is specify the configuration file you want to use through the commandline.
See: https://phpunit.de/manual/6.5/en/textui.html#textui.clioptions
So your command would look something like this:
phpunit tests\Unit\SomeTest.php --configuration phpunit.xml
or
phpunit tests\Browser\SomeTest.php --configuration phpunit.e2e.xml
I have a simple sbt application that uses typesafe-config library and is build using sbt-native-packager.
I build it using following command:
sbt universal:packageBin
Within the src directory I have following hierarchy:
main/resources/application.conf
test/resources/application.conf
staging/resources/application.conf
And my archive always ends up containing only the main version of application.conf
I'm looking for a easy way to include specific application.conf file based on for example java property passed during project build, but I'm unable to find anything.
Have you taken a look at the mappings facility, which allows you to add/remove files from the base layout? See Change-Remove Top Level Directory In Output in the official docs.
I've got 3 project defined in my Build.scala file:
common
services.dependsOn(common)
web.dependsOn(common)
Project Common contains /test/resources with logback-test.xml configuration which I would like to use for services and web tests.
This setup works fine in intelliJ with sbt-idea but when I try to run 'sbt test' from command line the logback-test.xml isn't copied over to /services/target/testClasses or /web/target/testClasses which means that the tests will use default slf4j configuration with useless tons of DEBUG info.
What should I do to force sbt to copy test resources from dependent project to others.
Thanks in advance
Dependencies don't include test configuration by default. You can change this like so:
common
services.dependsOn(common % "compile->compile;test->test")
web.dependsOn(common % "compile->compile;test->test")
More info here
Normally SBT looks for the build files at ./build.sbt and ./project/Build.scala. Is it possible to specify an alternate project root, so I can build a project not in the current working directory? I'm looking essentially for an equivalent to mvn -f /path/to/pom.xml but the docs have not provided me with any obvious answers.
(I should note that I want to do this at runtime rather than compile time. Essentially, I want to use sbt run-main to run arbitrary classes from my project, since I hate manual classpath wrangling. For various boring reasons I may need to do this from arbitrary location since the code may need the working directory to be something other than the project directory, so using cd might not do what I want. It's so trivial in Maven - I just assumed, perhaps unfairly, that there would be a simple equivalent in SBT)
I have something like this. I have project definition at X/build.sbt, X/MyOtherDefinitionWithSpecialThing/build.sbt, X/MySuperPublishConfig/build.sbt.
But my point of view to the problem is opposite. Instead of specify location of ./build.sbt and ./project/Build.scala I specify location of path to resources. The result is the same. It looks like:
sourceDirectory <<= (baseDirectory) (_ / ".." / "src")
target <<= (baseDirectory) (_ / ".." / "target")
This is allow to create single project with multiple definitions. This is worked with nested/hierarchical projects. But I use symbolic links (Linux OS) for hierarchical projects.
There is a file tree of one of my SBT plugins. Multiple build definitions and only one src/...
.
|-build.sbt
|-project
|---project
|-----target
|-------...
|---target
|-----...
|-project-0.11
|---build.sbt
|---project
|-----project
|-------target
|---------...
|-----target
|-------...
|-project-0.12
|---build.sbt
|---project
|-----project
|-------target
|---------...
|-----target
|-------...
|-...
|-src
|---main
|-----scala
|-------org
|---------...
|---sbt-test
|-----...
|-target
|---...
If this not solution of your problem please elaborate why you don't want use 'cd' command ;-)
-- For the updated use case:
I use shell wrapper and I have symlink to this one in every SBT project:
#!/bin/sh
#
here=$(cd $(dirname "$0"); pwd)
if [ ! -e "${here}/build.sbt" ]
then
echo build.sbt lost
exit
fi
cd ${here}
LOCAL_BUILD=true sbt-0.12 "$#"
I simply write /path/to/my/project/sbt 'show name' for example or /path/to/my/project/sbt run-main in your case.
As I discovered from this other answer, the sbt-start-script plugin is a better tool for this than sbt run-main. You can simply run sbt stage and you get an invocation script, with classpaths resolved, at target/start. According to the documentation, it needs to be run from the build root directory for inter-project dependencies to work, but for my simple use cases, this doesn't seem to be a problem.
I'm using sbt 0.10 to build a Scala project using just a build.sbt file instead of a full configuration.
Every time I start sbt it gives me the messages as follows:
[info] Set current project to default-ee699e (in build file:/Users/.../project/plugins/)
[info] Set current project to default-8febe7 (in build file:/Users/.../)
I did set the name and mainClass settings in the build.sbt file, so I don't know what I need to set to get the project names default-XXXX go away.
EDIT: the answer given below is correct in that this is cosmetic. If you switch to a full configuration of sbt, then it uses that project's name as opposed to default-XXXX however.
The message can be a bit misleading, it's not saying that you must "set the curent project", it's telling you what it's doing.
It sets the current project to the plugins folder, does it's stuff (compile, etc.), then sets the current project to your actual build folder and does it's thing once again.
You don't need to set anything else.