This is the problem I have. Flyway applies a schema to a database, and jOOq generates code from that schema. Compile compiles the code. So this is how it looks like:
Flyway runs -> jooq runs -> compilation
The problem is that, flyway for some reason, depends on runtime:fullClasspath, which in turn depends on compile:compile. I understand that flyway depends on compile for any Java migrations, but we don't have any Java migrations. Is there a way for flyway to depend only on runtime:dependencyClasspath and not on fullClasspath, so that I can define that,
(codegen in jOOQ) dependsOn flywayMigrate
compile dependsOn (codegen in jOOQ)
For some projects, we were facing similar problems with the gradle plugin, and it was solved with Flyway Gradle plugin - Circular dependency
I have no idea what to do with sbt.
Related
I have a multi module sbt/Scala project, and I want to write a maven plugin that depends on the scala code.
For the moment, I have the plugin in a separate project, using maven (maven-plugin packaging, and deps on the scala code). I therefore have 2 projects : one sbt and one maven. So I need to build (and publishM2) the sbt one and then build the other with maven.
Can the maven plugin be aggregated into the sbt build, so that I have only one multi-module project ?
Do I need to keep the pom.xml and "invoke" it from sbt ?
Can I build the mvn plugin directly in sbt (what about the packaging "maven-plugin" then) ?
I was wondering if SBT has something similar to the Gradle Wrapper?
I would like to use it on a CI server without having to install SBT first.
The documentation mentions a sbt-launcher, but that seems to be geared towards running actual application instead of builds.
Yes, sbt-extras is a bash script that you can commit to your repository to act like the gradle wrapper.
The sbt-extras project is centered around a stand-alone script called sbt which can be directly used to run sbt without having it on the machine first.
The script has logic to determine the proper version of sbt for the project, download the correct version of the sbt jar, and then run the tasks through sbt.
If you copy the sbt script into your project, you can simply call it — from your CI server, locally, or wherever — to run sbt tasks without needing sbt installed separately.
In Gradle, there is a concept of a buildscript dependency, in that you can add an external dependency that the build script depends on to run. This is similar to SBT's plugins, except way more lightweight. With Gradle, I can add X as a dependency and then write Groovy code using the contents of X. I need to use an external Java library inside of my build script and the mechanisms to do this are far from obvious to me in SBT.
With SBT, the closest thing I've found in the documentation is addSbtPlugin, which works great if there is an X SBT plugin, but it isn't in this case.
Sbt builds are recursive, you can add a project/build.sbt file then add libraryDependency += ... to it.
I am in the process of creating a plugin that will modify both the compile:compile and test:test tasks. My ultimate aim is to be able to do sbt monkjack or sbt monkjack:test (either is fine). In the compile:compile scope I need to add a compiler plugin, and in the test:test scope I need to run some code after the tests have finished.
My first attempts were around trying to create a custom configuration but which to extend, compile or test, was unclear as both are needed (At the moment I have two, and I copy the CustomTest into the CustomCompile and then run monkjack:test). My second attempts were focusing on a custom task that in turn invoked (compile in Compile).value and (test in Test).value after setting various options.
I realize my knowledge of SBT tasks and how they are related/inherited/scoped is not great.
Q1. Is there a chain of tasks like in maven? In maven if you execute test, it will execute the other phases in order. So mvn clean test will automatically run prepare-sources, compile, etc etc. So in SBT if I run sbt test how are the other tasks automatically executed.
Q2. If you execute a task with a custom config, eg sbt millertime:test will that config propagate to the other tasks that run. Eg, is this the same as sbt monkjack:compile monkjack:test or the same as sbt compile monkjack:test or neither :)
Q3. How do tasks know which is their default config? If I do sbt compile how does SBT know that means sbt compile:compile?
Q4. Which is the best way to go here, a custom configuration or a new task.
The goal is to have a standalone Play Framework (2.2) application having an additional status window open containing some javafx (javafx-8) elements.
Since JavaFX classes are now on the default runtime classpath for an Oracle Java 8 implementation using javafx.* in my classes and compiling with sbt should just be fine.
However sbt can't find these classes and quits with
play.api.UnexpectedException: Unexpected exception[NoClassDefFoundError: javafx/application/Application]
when executing
..\path-to-play-framework-2.2\play project run
The best way to fix this problem seems to be the modification of build.sbt in the project directory. What can I do to add the missing (class) path?
Sadly JavaFX doesn't link that easily to an sbt build. You need to set your JAVA_HOME environment variable and do modifications to your build file.
Here I have a repository where this is set up. The important bit if you are using an sbt build rather than a scala build is this one:
unmanagedJars in Compile += Attributed.blank(
file(System.getenv("JAVA_HOME") + "/jre/lib/jfxrt.jar")),
fork in run := true
The reason for this is that jfxrt.jar is the archive containing the JavaFX runtime and it is not included in the classpath of an sbt project by default.
Anotherway is to set the Classpath for sbt. This can be done on the machines which can't resolve JavaFX.
SBT_OPTS="-Xbootclasspath/p:/usr/share/java/openjfx/jre/lib/ext/jfxrt.jar"