ok, 3 bugs below I 'think' but if they are not let me know. (I do LOVE the customizability of gradle and these are corner case bugs for sure but still inconsistent behaviors)
gradle version 2.14.1
Eclipse Neon 4.6.0 build id 20160613-1800
Buildship, Eclipse Plugins for gradle 1.0.20v20160901-0734
I LOVE making things seamless so I really wanted to make things seamless on using eclipse with this project https://github.com/deanhiller/webpiecesExample as a test run.
BUG 1: Instead, I found a bug in the eclipse buildship gradle plugin that does not bring in -parameters to the project settings like ./gradlew eclipse does :(.
I have the following that makes my gradle compile with parameters (and ./gradlew eclipse generates the correct settings file while buildship ecilpse gradle plugin does not)
[compileJava, compileTestJava]*.options.collect {options ->
options.compilerArgs.add '-parameters'
}
BUG 2: so then I switch to ./gradlew eclipse. That then has a different bug in that it generates two src/main/java when using a section like this.....
sourceSets {
//For testing, we need to put the html files on the classpath which are co-located with the controllers
extraTest {
resources {
srcDirs = ["src/main/java"]
includes = ["**/*.html", "**/*.tag"]
}
}
test {
resources {
//This ADDS src/test/java/**/*.html and we still read in src/test/resources/**
source extraTest.resources
}
}
}
BUG 3: In trying to figure this all out, I finally found out gradlew cleanEclipse does not clean stuff that was generated by gradlew eclipse specifically the .settings folder :(. I basically can do a ./gradlew eclipse and then gradlew cleanEclipse and they don't delete what was created :(.
FEATURE REQUEST 1: The application plugin I had to hack like this....(definitely read my comments as the solution ended up not working and I had to hack it differently).
How to configure gradle application plugin to set my user.dir to the location of the script?
You should totally be able to tell the application plugin that one desires the application directory to be where the program starts no matter what directory I start the application from....that was very frustrating to fix all that.
I still love gradle. I am just getting very down and dirty in the details here and hope that eventually these nitpicks can be fixed.
Related
The issue is that executing gradle commands via the wrapper will cause the compileKotlin step to fail with different mentions that it is unable to find javafx-related classes/packages.
I'm setting up the whole project structure so that all the build system is not dependent on the IDE but rather relies on using the wrapper to execute all the build.
But executing a gradlew.bat build on the command line will fail with the mentioned errors. However, executing a "build" via the embedded Gradle in Intellij works. (attached pictures)
A few things to mention:
kotlin version 1.3.50 (latest version)
gradle version in wrapper properties is 5.6.2
Build failure pic:
Build working with Gradle from Intellij:
Build from Intellij button:
Gradle config in Intellij:
I have already tried plenty of suggestions mentioned on several topics related to this one (Invalidated caches + Restart, re-importing project, generating the wrapper again, all the usual solutions you will see for this issue). None of them worked, so the issue remains. I tried switching between versions of Gradle and running the wrapper again and that didn't work, it seems that version specified for the wrapper and the Gradle distribution it pulls down does not matter since the build fails with exactly the same error on all versions.
Note that this happened quite recently after an update of Intellij Idea from version 2019.2.2 to 2019.2.3, I really hope this isn't the root issue behind it.
This is not the only project with Gradle kotlin-dsl using javafx that is failing right now: even creating a new empty project via the tornadofx-plugin for Intellij and migrating it to the kotlin-dsl will yield the same results: compileKotlin task will fail. Besides that, several older projects with gradle kotlin-dsl that were building fine from the wrapper suddenly started out giving the same error.
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
import edu.sc.seis.launch4j.tasks.DefaultLaunch4jTask
plugins {
application
id("edu.sc.seis.launch4j") version "2.4.6"
kotlin("jvm") version "1.3.50"
}
group = "genericdesktopapp"
version = "1.0-SNAPSHOT"
application {
mainClassName = "root/RootKt"
}
repositories {
mavenCentral()
mavenLocal()
}
dependencies {
implementation(kotlin(module = "reflect", version = "1.3.50"))
implementation(kotlin("stdlib-jdk8"))
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.0-RC")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-javafx:1.3.0-RC")
implementation("org.slf4j:slf4j-api:1.7.21")
implementation("com.lmax:disruptor:3.3.4")
implementation("org.apache.logging.log4j:log4j-slf4j-impl:2.6.2")
implementation("org.apache.logging.log4j:log4j-api:2.6.2")
implementation("org.apache.logging.log4j:log4j-core:2.6.2")
implementation("commons-io:commons-io:2.6")
implementation("org.apache.commons:commons-text:1.6")
implementation("com.github.salomonbrys.kodein:kodein:4.1.0")
implementation("commons-validator:commons-validator:1.6")
implementation("no.tornado:tornadofx:1.7.17")
testImplementation("org.junit.jupiter:junit-jupiter-api:5.1.0")
testRuntime("org.junit.jupiter:junit-jupiter-engine:5.1.0")
}
tasks.withType<KotlinCompile> {
kotlinOptions.jvmTarget = "1.8"
}
tasks.withType<DefaultLaunch4jTask> {
outfile = "GenericToolbox.exe"
mainClassName = "root.Root"
productName = "GenericToolbox"
}
I expect that when I run in the command line gradlew.bat build or ./gradlew build for it to complete normally and find the related classes from javafx, like it happens when using Intellij Gradle build command.
This issue should not even happen since I'm keeping everything at java-8, I know this issue is supposed to happen to versions beyond 8. I'm also seeing in the gradle caches the stdlib-jdk7 from kotlin, I have nowhere nothing related to jdk7 specified in my Intellij configurations or in the build script, so that is also something weird happening. (even cache reset made gradle pull it back in the cache, so I'm thinking it's probably the embedded kotlin compiler from gradle that is that version).
Edit: An easy way of reproducing it (just tested it right now).
Open a command line and create a new project with gradle kotlin dsl:
mkdir testproject
cd testproject
gradle init --dsl kotlin
On the project that was generated, run the gradlew.bat build or ./gradlew build and see the compileKotlin working okay and the build is successful.
On the same project, in the generated App.kt file, in the main function, add a simple val stage = Stage() (imported from javafx).
Run again the gradlew.bat build and see that it now fails since it doesn't find javafx.
I have managed to find a way around this issue, however, it's not a proper solution since I still haven't found the cause for why that was happening, but I'll post it in case anyone else will have this issue and maybe it will be helpful.
The solution is (weirdly enough) to specify the jdk version that gradle will use when running the commands through the wrapper:
gradlew.bat build -Dorg.gradle.java.home=---path-to-jdk---
I have checked my environment variables and the java home variable already points to that same location, so somehow I believe gradle doesn't find the java home and uses something embedded (which is most likely something above java 8) which produces that error. Running through the Intellij gradle works because it is using the embedded jdk in Intellij which is also java8, so that explains why they were working through the Intellij build button from the Gradle side-window.
If anyone finds the root cause or has some other suggestion, please, feel free to share your knowledge.
We have a Gradle 5.x multi-module project consisting of four modules written in Java and a plugin written in groovy. When the modules were in separate git repos, we had coverage for the plugin because the tests ran. With everything in one repo, it now no longer runs the groovy tests, yet it runs all of the Java tests. We've tried setting the classes directories explicitly in test {
jacoco {
includes = [dirs here...]
but it has no effect. There doesn't seem to be anything online about this problem. Has anyone seen it? If so, what's the fix?
I have a build.gradle file that I want to use to build a Spring Boot microservice for multiple projects. I have created a custom library with some classes that should not be in all of the projects but I don't want to have to edit the build.gradle file when I build the microservice depending on which project I will use it in.
How can I add a command/parameter to gradle build that can add runtime libraries to the Spring Boot app?
Something like (just an exaple):
gradle buildDocker -PaddRuntime=com.skios.lib:lib-common:0.2.35
Thanks for any directions
I am not sure I understand your issue fully and thus not convinced this is the best solution.
But since a Gradle build script accepts code, you can have conditionals in a dependencies block:
dependencies {
if (project.hasProperty('addRuntime')) {
runtimeOnly('com.skios.lib:lib-common:0.2.35')
}
}
and then on the command line: ./gradlew buildDocker -PaddRuntime
IntelliJ IDEA 2016.3 add the ability to delegate build/run to Gradle.
It's clear that when the delegate option is on Gradle is doing everything.
My question is what exactly IntelliJ is doing when this option is off?
I'm asking this because I have custom code inside my Gradle files and it does not seems like this code is executed when building in IntelliJ. When I run gradlew build everything works just fine.
IntelliJ has its own build system, called JPS, which uses the IntelliJ IDEA project and .iml files as the project model. When you're using IntelliJ IDEA's default build system to build the project, it does not execute any code in Maven or Gradle files; it uses its own logic, which can only be extended by writing plugins to JPS.
I had created a groovy project. It worked by itself.
After some additions I had to add a new jar of a new library into the imports.
While the whole workspace runs on Gradle, I added the appropriate Maven reference to the gradle.build file.
After running gradle cleanEclipse Eclipse the new library works OK.
But. All project references to the Groovy libraries disappeared. Foolish me, I had to put some references to them into the gradle.build, too.
The list of libraries:
groovy.util.slurpersupport
groovy.xml
org.codehaus.groovy.tools.xml
groovy.lang
But I don't know how to include them into gradle.build. I can't found them in maven repository. And even so, I have them installed in my Eclipse, and I should take these. And I can't google any help, because gradle groovy gives the results on how to call gradle from groovy, not vice versa.
Moving from plain Groovy to Gradle won't help, it is really about gradle support for calling a java library from groovy.
I have nothing against getting dependencies from Maven rep., but I don't know how to do it in my case - The problem is, that I have Eclipse 3.6. And I should use the last version of groovy for Eclipse 3.6. So, I have installed it from http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/. And I don't know what is the equivalent version in Maven - there is no info about it.
There was some error in the groovy in Eclipse installation. Now after running gradle cleanEclipse Eclipse while build.gradle has NO dependencies to groovy, almost everything runs OK, I only have to add the groovy nature to the project