I am getting errors when I try to stage my application using sbt clean compile stage:
[error] Not a valid command: stage
[error] Not a valid project ID: stage
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: stage
[error] stage
[error] ^
I have done this hundreds of times on other machines without a problem. I have SBT 0.13.5 -- has anyone seen this before? I have read this other post, but I'm not on Heroku. Thanks.
After the comments above I realized that you just wanted to have stage command without bringing the entire Play foo in.
The stage command is part of sbt-native-packager that:
The goal [of the plugin] is to be able to bundle up Scala software built with SBT for native packaging systems, like deb, rpm, homebrew, msi.
One of the features of the sbt-native-packager plugin is the stage command that
> help stage
Create a local directory with all the files laid out as they would be in the final distribution.
Just add the following to project/plugins.sbt to have the plugin available in the project (after the comment of Muki the example uses the latest version 1.0.0-M1 with the autoplugin feature):
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.0-M1")
You will also have to add the following to build.sbt:
enablePlugins(JavaAppPackaging)
And that's it! You're all set now.
Execute stage.
> stage
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Updating {file:/Users/jacek/dev/sandbox/command-build-scala/}command-build-scala...
[info] Wrote /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.pom
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.jar ...
[info] Done packaging.
[success] Total time: 0 s, completed Nov 5, 2014 2:55:55 PM
After lots of digging, I found out 'stage' is implemented by a plugin from the Play framework, which I do use in my other projects and explains why sbt was accepting the stage command.
Related
I have a multi-project build, and want to run tests after starting two Docker containers. This is my custom task:
runTestsWithDocker := Def.taskDyn {
startDirectoryServer.value
val containerId = buildOrStartTestDatabase.value
Def.task {
(test in Test).value
sLog.value.info("running inside dynamic task")
containerId
}
}.value
As you can see from the output below, the Docker containers are started, and the log message is written from the dynamic task. However, there's no test output (and the build executes far too quickly for the tests to have run).
> runTestsWithDocker
[info] logging into ECR registry 123456789012.dkr.ecr.us-east-1.amazonaws.com
[info] checking repository for image container1:1.2.3-1200
[info] successfully logged-in to ECR registry 123456789012.dkr.ecr.us-east-1.amazonaws.com
[info] DockerSupport: pulling 123456789012.dkr.ecr.us-east-1.amazonaws.com/container2:latest
[info] DockerSupport: docker run -d -p 389:389 123456789012.dkr.ecr.us-east-1.amazonaws.com/container2:latest
[info] container ID: 80d16a268c6e13dd810f8c271ca8778fc8eaa6835f2d0640fa62d032ff052345
[info] image already exists; no need to build
[info] DockerSupport: pulling 123456789012.dkr.ecr.us-east-1.amazonaws.com/container1:1.2.3-1200
[info] DockerSupport: docker run -d -p 5432:5432 123456789012.dkr.ecr.us-east-1.amazonaws.com/container1:1.2.3-1200
[info] container ID: 2de559b0737e69d61b1234567890123bd123456789012d382ba8ffa40e0480cf
[info] Updating {file:/home/ubuntu/Workspace/mybuild/}mybuild...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] running inside dynamic task
[success] Total time: 2 s, completed Jun 5, 2019 9:05:20 PM
I'm assuming that my scope is incorrect, and that I need to refer to test in some other scope, but I have no idea what that might be (I've tried Compile and ThisBuild as random stabs in the dark).
I've also seen (test in Test).result.value from other questions in SO. Thinking that maybe the test task was doing something non-standard I tried it, but with the same (non) result.
Lastly, I'm running SBT 0.13.16, so any convincing argument (as in a bug report) that it's a problem with that version would make me upgrade sooner than planned (my current goal is to refactor the build then upgrade).
Update: here's the output from inspect. It doesn't show the dependency on test, but I'm assuming that's because it's invoked from a dynamic task.
> inspect runTestsWithDocker
[info] Task: java.lang.String
[info] Description:
[info] Runs the test suite, after starting the LDAP server and running/initializing the test database
[info] Provided by:
[info] {file:/home/ubuntu/Workspace/mybuild/}mybuild/*:runTestsWithDocker
[info] Defined at:
[info] /home/ubuntu/Workspace/mybuild/build.sbt:597
[info] Dependencies:
[info] mybuild/*:buildOrStartTestDatabase
[info] mybuild/*:startDirectoryServer
[info] mybuild/*:settingsData
[info] Reverse dependencies:
[info] mybuild/*:publishTestDatabase
[info] Delegates:
[info] mybuild/*:runTestsWithDocker
[info] {.}/*:runTestsWithDocker
[info] */*:runTestsWithDocker
Update: if I specify a single sub-project, it correctly runs the tasks in that sub-project.
runTestsWithDocker := Def.taskDyn {
startDirectoryServer.value
val containerId = buildOrStartTestDatabase.value
Def.task {
(test in (subproject,Test)).result.value
containerId
}
}.value
So it looks like maybe the root project isn't aggregating? We're relying on the "default root" project, so I think my next change will be to create an explicit root project.
It turned out that the default root project was not in fact "aggregat[ing] all other projects in the build." Once I created this project and explicitly aggregated the other sub-projects under it, I was able to specify my task like so:
runTestsWithDocker := Def.taskDyn {
startDirectoryServer.value
val containerId = buildOrStartTestDatabase.value
Def.task {
(test in (root,Test)).result.value
containerId
}
}.value
:shrug:
I'm trying to follow Travel Demo - for developers # https://documentation.magnolia-cms.com/display/DOCS56/Travel+Demo+-+for+developers
as suggested I've cloned project
build it with skipped checkstyle option (already feel weird if I can't build project without undocumented tricks)
Build succeed, but I have no clue what to do with it:
There no war files, only jars.
I know about training-developer-project bundle which I was able to build and run on local Tomcat
What I would like to do is:
install Travel Demo project in blank magnolia web app maven project which I generated with maven archetype
Clarification: My idea was not just to install travel-demo as dependency but make it a part of my study project.
Update #Ducaz035: Running mvn -e -X clean install gives errors in checkstyle plugin:
[INFO] Starting audit...
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\model\NavigationAreaModelTest
.java:48: Missing a Javadoc comment.
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\setup\SetupDemoRolesAndGroups
TaskTest.java:54: Missing a Javadoc comment.
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\setup\TravelDemoModuleVersion
HandlerTest.java:75: Missing a Javadoc comment.
Audit done.
[INFO] There are 3 errors reported by Checkstyle 6.1.1 with magnolia-build-resources/checkstyle.xml ruleset.
[ERROR] src\test\java\info\magnolia\demo\travel\model\NavigationAreaModelTest.java[48] (javadoc) JavadocType: Missing a Javadoc co
mment.
[ERROR] src\test\java\info\magnolia\demo\travel\setup\SetupDemoRolesAndGroupsTaskTest.java[54] (javadoc) JavadocType: Missing a Ja
vadoc comment.
[ERROR] src\test\java\info\magnolia\demo\travel\setup\TravelDemoModuleVersionHandlerTest.java[75] (javadoc) JavadocType: Missing a
Javadoc comment.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Magnolia Travel Demo (parent pom) .................. SUCCESS [ 4.489 s]
[INFO] Magnolia Travel Demo Module ........................ FAILURE [ 34.003 s]
You have to put in into the webapp, you are talking about the bundle so add the travel-demo to it as maven dependency. Alternative you can drop the jar to /libs folder and Magnolia will it pick up automatically. For more detail please check
https://documentation.magnolia-cms.com/display/DOCS55/Installing+a+module
Cheers,
I have a multi-project sbt where I use sbt-release plugin. Everything works fine if I run release in a sub-project
> project reporter
[info] Set current project to reporter (in build file:/source/storage-integ/)
> release
[info] Starting release process off commit: c069698baf8bb6fca611ab4e7e086398aab473c5
[info] Checking remote [origin] ...
But this doesn't work when I run "sbt reporter/release" from cli. Where as "sbt reporter/compile" or "sbt reporter/assembly" do work.
$ sbt reporter/release
[warn] Executing in batch mode.
[warn] For better performance, hit [ENTER] to switch to interactive mode, or
[warn] consider launching sbt without any commands, or explicitly passing 'shell'
[info] Loading global plugins from /home/vagrant/.sbt/0.13/plugins
[info] Loading project definition from /source/storage-integ/project
[info] Set current project to root (in build file:/source/storage-integ/)
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: release (similar: releaseVcs, rpmRelease, rpm-release)
[error] reporter/release
This looks very similar to another SO post. I tried adding releaseSettings to build.sbt as suggested but it throws error
build.sbt:62: error: not found: value releaseSettings
I tried import sbtrelease.Release._ but that throws
error: object Release is not a member of package sbtrelease
At this point I feel the solution mentioned is no longer valid. Also, I don't see any reference to releaseSettings in sbt-release readme. Any idea how to get this working?
sbt.version = 0.13.15 && sbt-release: "1.0.6"
The release settings should be only in your root project. So, in order to have that:
First, your build.sbt could be something like this
lazy val root: Project = project.in(file("."))
.settings(Releases.settings: _*)
.aggregate(module1, module2)
Then, your project/Releases.scala like:
object Releases {
// You need to custom these to reflect your actual procedure
private val releaseProcess = Def.setting {
Seq[ReleaseStep](
checkSnapshotDependencies,
inquireVersions,
runClean,
runTest,
setReleaseVersion,
commitReleaseVersion,
tagRelease,
publishArtifacts,
setNextVersion,
commitNextVersion,
pushChanges
)
}
val settings = Seq(
releaseCommitMessage := s"Set version to ${(version in ThisBuild).value}",
releaseTagName := (version in ThisBuild).value,
releaseProcess := releaseProcess.value
)
}
By default you need a version.sbt with your current version. Lets say:
version in ThisBuild := "1.0.0-SNAPSHOT"
Then just:
sbt release
So, I have a SBT project, with two custom tasks jooq:codegen and flyway:migrate from [ https://github.com/sean8223/jooq-sbt-plugin, https://github.com/sean8223/flyway-sbt-plugin ]
Not that it is relevant here, but the flyway:migrate task creates the schema in the database, and jooq:codegen generates code from the schema. Hence, it is imperative that flyway:migrate runs before jooq:codegen. So, I added the following line in my build.sbt
(codegen in JOOQ) <<= (codegen in JOOQ) dependsOn (migrate in Flyway)
Also, compile needs the generated code from jooq:codegen, but the plugin takes care of it by default.
Here is the weird part. When I run sbt compile, I get:
~/N/p/d/davion git:data-access ❯❯❯ sbt compile
[info] Loading project definition from /Users/rohan/Nomadly/projects/davion-projects/davion/project
[info] Set current project to davion (in build file:/Users/rohan/Nomadly/projects/davion-projects/davion/)
[info] Done updating.
[info] Initialising properties : /jooq-config4460313300896426081.xml
... OUTPUT TRUNCATED ...
[info] Table records generated : Total: 669.172ms, +44.536ms
[info] Routines fetched : 0 (0 included, 0 excluded)
[info] Packages fetched : 0 (0 included, 0 excluded)
[info] GENERATION FINISHED! : Total: 688.254ms, +19.082ms
[info] Compiling 7 Scala sources and 17 Java sources to /Users/rohan/Nomadly/projects/davion-projects/davion/target/classes...
[success] Total time: 24 s, completed 14 May, 2015 12:13:35 PM
So, the flyway:migrate task doesn't run. But when I run sbt jooq:codegen, this happens:
~/N/p/d/davion git:data-access ❯❯❯ sbt jooq:codegen
[info] Loading project definition from /Users/rohan/Nomadly/projects/davion-projects/davion/project
[info] Set current project to davion (in build file:/Users/rohan/Nomadly/projects/davion-projects/davion/)
[info] Flyway (Command-line Tool) v.2.0.3
[info]
[info] Current schema version: 6
[info] Schema is up to date. No migration necessary.
[info] Initialising properties : /jooq-config6431105742854017589.xml
[info] License parameters
... OUTPUT TRUNCATED ...
I have no idea why this is happening. If a task chain is setup where 'A' depends on 'B' which depends on 'C', then shouldn't running 'A' execute both 'C' and 'B' (and in that order)? Why does 'C' not run as a transitive dependency and how can I remedy this?
I've migrated my project to 0.13.5 and started using the xsbt-web-plugin.
I'd like to configure logback to be using a configuration file outside the classpath which is set by a system property logback.configurationFile (so I can keep the logconfig outside the war file).
Previously I would simply set:
System.setProperty("logback.configurationFile", "/some/path/logback.xml")
inside the project/build.scala and logback would pick it up.
However, after upgrading sbt to 0.13.5 and migrating to the xsbt-web-plugin system properties set in sbt don't seem to be available at runtime(jetty).
I've tried setting system properties in different ways, also by passing it along using the -D flag when starting sbt.
On the sbt console I can see the property:
eval sys.props("logback.configurationFile")
[info] ans: String = /some/path/logback.xml
But it's not available inside the webapp.
Any ideas on how to set system properties to be available inside the webapp?
I've tried both jetty() and tomcat(). Same behaviour.
Update:
I ended up with:
jetty(options = new ForkOptions(runJVMOptions = Seq("-Dlogback.configurationFile=/some/path/logback.xml")))
that works.
Use javaOptions in container += "-Dlogback.configurationFile=/some/path/logback.xml" as described in Set forked JVM options.
javaOptions alone (without in container) should work, too, as could be seen in inspect actual under Dependencies and Delegates:
[play-new-app] $ inspect actual container:javaOptions
[info] Task: scala.collection.Seq[java.lang.String]
[info] Description:
[info] Options passed to a new JVM when forking.
[info] Provided by:
[info] {file:/Users/jacek/sandbox/play-new-app/}root/container:javaOptions
[info] Defined at:
[info] /Users/jacek/sandbox/play-new-app/build.sbt:26
[info] Dependencies:
[info] */*:javaOptions
[info] Delegates:
[info] container:javaOptions
[info] *:javaOptions
[info] {.}/container:javaOptions
[info] {.}/*:javaOptions
[info] */container:javaOptions
[info] */*:javaOptions
[info] Related:
[info] */*:javaOptions