I have a multi-module build, and would like to run tests for different sub-projects independently.
Is there a way to do this in sbt, e.g. if my multi-project build has a core and commons projects, I'd like to only run test in the commons project.
Run sbt commons/test. See detailed explanation in Scopes.
You may also use the combination of two commands from sbt - changing the current project using project and executing test afterwards.
sbt "project commons" test
You can also use
sbt "; project commons; test"
It you are running sbt in interactive mode:
> project commons
> test
You can switch back to core with:
> project core
Never mind, I came across this:
How to execute package for one submodule only on Jenkins?
sbt "project core" test
Another way to do this.
Get into SBT interactive mode
> sbt
sbt:core> commons / test
No need to switch between projects.
to run sbt test only for ONLY the submodules having added, modified on deleted files, if you use git:
while read -r proj ; do sbt "project $proj" test ; \
done < <(git status --porcelain | cut -c 3- | cut -d/ -f1
There is another way to have sbt open for a particular module.
Go to the location of the module directory and type in the "sbt" command.
sbt will then open in interactive mode for that module only
Related
VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist
Getting different mutation scores each time I run Stryker from the root of the project which has multiple test projects.
Does stryker support running '.sln' files from the root of the project?
Command used from the root of the project:
dotnet stryker --solution-path "Project.sln"
Env: Linux, Windows, .NET core
Any insight is appreciated. Thank you.
Solution mode isn't working properly yet thus it's not really documented. You can use this script for now - a little raw but works.
I have faced the same issue previously and conceded defeat. The path of least resistance for me in terms of unit test code coverage and also stryker mutation testing is to have all unit tests in a single project and execute stryker from the folder where the test.csproj is location. My build pipeline script (running in GitLab on Linux) looks something like this:
- dotnet build
- cp ./resources/stryker/stryker-config.json ./*.Tests
- cd ./*.Tests
- dotnet stryker
It first builds the whole solution, then copies a known config file into the test project folder, then change directory into that folder and execute stryker.
I am migrating from activator from 0.13.x to sbt 1.x.
I used to compile my modules like this $ activator clean compile publish-local -Dversion=1
Now, I am trying to do it with sbt since activator has been deprecated, but I can not find how I should migrate to something similar like $ sbt clean compile publish-local -Dversion=1?
Activator (the CLI part) was just a wrapper around sbt with some custom commands. So what you wrote should work the same, expect that the snake-case was deprecated in favor of the camelCase:
sbt clean compile publishLocal
If you need to pass a var to the Java runtime with -D you have to place it before any commands: sbt -Dversion=1 ....
Notice that you use batch mode to run the commands:
Running in batch mode requires JVM spinup and JIT each time, so your build will run much slower. For day-to-day coding, we recommend using the sbt shell or Continuous build and test feature described below.
To follow this recommendation, just run sbt and then enter those commands one by one. Or to run them all sequentially, enter ; clean; compile; publishLocal.
Assuming this folder structure
SampleApp
global.json
Src
Web
project.json
Startup.cs
...
Model
project.json
Startup.cs
...
how does one compile both projects using dotnet? (from command line, not in visual studio)
If you run dotnet build at the root folder level you get
Could not find file .. project.json
I can see there is this outstanding enhancement on the CLI repo but that is from Feb2.
Any script would have to take dependencies into account before just blindly calling dotnet on all src sub-folders.
The dotnet build command accepts glob patterns. So you can do this:
dotnet build Src/**/project.json
There's no such a tool yet. Even KoreBuild, the tool that the ASP.NET team uses, goes blindly in each folder and invokes dotnet build/pack.
The nice thing is that dotnet build is now smart enough to not recompile the dependencies if they haven't changed, so that's not a problem anymore.
For linux I'm using:
for p in $(find . -name *.csproj); do dotnet build $p; done
I had a similar requirement. This is my workaround:
#echo off
for /D %%d in (*) do (
cd %%d
cd
dotnet restore
dotnet build
cd ..
)
exit /b
Use GNU Make. I use it to build my projects. all you have to do create a Makefile in your project root folder. You can nest Makefiles in directories and have a Top Level Makefile that runs the subdirectories. then you set up Makefiles for each of your "Sub Projects" folders and run any comandline tool. with dotnet core is is dotnet .
Wait... GNU - "GNU is not Unix" that's a Unix/Linux application... I run windows. Well the good news is you can do this is in windows. I'm using make.exe through my git-bash installation (git for windows). You will have to go find the cygwin port of make. (google: "make for git-bash") Then install it to your bin directory under the cygwin folder. You could also just install cygwin if you really wanted to.
The nice thing about using Gnu-Make is it is universal. Since dotnet core is platform agnostic, every environment Mac/FreeBSD/Linux have "make" most likely already installed. Adding it to your Windows machine and projects to me makes a lot of sense. Since you project can now be built by everyone the same way.
some of my projects need to build docker containers with dockerfiles, or snap packages, deploy to test, etc... Make (pardon the pun) makes it easy.
Here is a sample of simple projects Makefile. Running 'make' by itself is like saying 'make all' you could set up a command like 'cd ./subdir; make' as one of your .phoney directives. (Google: "Makefile documentation")
project_drive?=/c/prj
nuget_repo_name?=Local_Nuget_Packages
local_nuget_dir?=$(project_drive)/$(nuget_repo_name)
RELEASE_VERSION:= `grep "<Version>" *.csproj | cut -d '>' -f 2 | cut -d '<' -f 1`
.PHONEY: clean release test doc nuget install debug_nuget debug_install
all: doc MSBuild
test:
./test.sh
MSBuild:
dotnet build
clean:
dotnet clean; dotnet restore
release:
dotnet build -c Release
doc:
doxygen ./Doxyfile.config
nuget: release
dotnet pack -c Release
install:
cp ./bin/Release/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
debug_nuget: MSBuild
dotnet pack
debug_install:
cp ./bin/debug/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
What's missing is that you can also use the commands on project.sln files if you do not have project.json
dotnet build src/**/project.json
-- or --
dotnet build src/project.sln
same goes for dotnet test
I'm trying to set up a Scala project, built using SBT, that will consist of a library and several command-line tools to do various things using that library. The library and tools are going to depend on another Scala project which I've installed into my local Ivy cache with sbt publish-local.
I've never used SBT before, so I'm a bit lost as to how to set this up. I would like several Linux executables or shell scripts in my top-level project directory, each of which executes a main() methods defined in a Scala file, and all of which depend on a single library. How do I get that sort of setup with an SBT project?
The way I'm thinking this will have to work is as an SBT configuration with multiple projects, and a bunch of wrapper shell scripts that execute sbt run in the appropriate project. However, when I run sbt run in my current single-project setup, I get, in addition to my program's intended output, a bunch of SBT noise:
Loading /pod/home/anovak/build/sbt/bin/sbt-launch-lib.bash
[info] Loading project definition from /pod/home/anovak/sequence-graphs/project
[info] Set current project to Sequence Graph API (in build file:/pod/home/anovak/sequence-graphs/)
[info] Running SequenceGraphs
Sequence Graphs are great!
[success] Total time: 2 s, completed Jan 6, 2014 6:01:17 PM
I would like my wrapper scripts to be able to run my command-line tools without seeing anything from SBT on screen at all. I think the [info] and [success] messages can be suppressed by messing about with the project's log level settings, but would that eliminate the "Loading..." line as well? If not, is there some other way to run an SBT project "on its own", without much/any interference from SBT?
I think what you need is one root project - sequence-graphs - with two submodules - library and cmd-tools.
project/build.properties would be as follows:
sbt.version=0.13.1
build.sbt for the root project would be as follows:
lazy val root = project in file(".") aggregate (library, `cmd-tools`)
lazy val library = project
lazy val `cmd-tools` = project dependsOn library
With only these two files you can run sbt and do projects to see the projects available.
[root]> projects
[info] In file:/Users/jacek/sandbox/so/sequence-graphs/
[info] cmd-tools
[info] library
[info] * root
At the same time SBT will create necessary subdirectories for the submodules.
With the project layout you start developing your own command-line tools in cmd-tools submodule.
To make things simple, I assume that a simple App-extending applications are enough.
cmd-tools/Hello1.scala
object Hello1 extends App {
println("Hello1")
}
cmd-tools/Hello2.scala
object Hello2 extends App {
println("Hello2")
}
With these two Hellos you can run cmd-tools/run from SBT shell in the root project.
[root]> cmd-tools/run
[info] Compiling 2 Scala sources to /Users/jacek/sandbox/so/sequence-graphs/cmd-tools/target/scala-2.10/classes...
Multiple main classes detected, select one to run:
[1] Hello2
[2] Hello1
Enter number:
The same could be run from the command line as sbt cmd-tools/run:
jacek:~/sandbox/so/sequence-graphs
$ sbt cmd-tools/run
[info] Loading global plugins from /Users/jacek/.sbt/0.13/plugins
[info] Loading project definition from /Users/jacek/sandbox/so/sequence-graphs/project
[info] Set current project to root (in build file:/Users/jacek/sandbox/so/sequence-graphs/)
Multiple main classes detected, select one to run:
[1] Hello1
[2] Hello2
Enter number: 1
[info] Running Hello1
Hello1
[success] Total time: 4 s, completed Jan 9, 2014 9:44:39 PM
Let's start it over as well as disable infos and [success]es messages.
jacek:~/sandbox/so/sequence-graphs
$ sbt --error 'set showSuccess := false' cmd-tools/run
Multiple main classes detected, select one to run:
[1] Hello1
[2] Hello2
Enter number: 1
Hello1
There's also the runMain command that Runs the main class selected by the first argument, passing the remaining arguments to the main method.
With that and the other examples you could have a sample command-line script to execute Hello1 as follows:
sbt --error 'set showSuccess := false' 'cmd-tools/runMain Hello1'
It could be even simpler when you use the sbt-onejar plugin that can Package your project using One-JAR™ With the plugin you don't have to use SBT after you distribute your command-line tools.
Quoting the plugin's documentation:
sbt-onejar is a simple-build-tool plugin for building a single executable JAR containing all your code and dependencies as nested JARs.
Please note that the Officially supported packages of SBT add some additional checks and printouts, i.e. tgz comes with bin/sbt script that does the following (amongst the other things):
echo "Loading $(dirname "$(realpath "$0")")/sbt-launch-lib.bash"
It's not an integral part of SBT itself, but the script itself that wants to do as much as possible so an end user is, say, happy. In your case, you are not necessarily happy, so either remove the line from the script or follow the steps as described in Manual Installation.