I'm working on a Java 11 application that uses the java module system. I need to use reflection to access an internal function of the JavaFX library. The java module containing that function doesn't export it, so I get the following error when I run the gradle build task:
import com.sun.javafx.tk.TKStage;
^
(package com.sun.javafx.tk is declared in module javafx.graphics, which does not export it to module com.sampleapp)
I believe that means I need to do --add-exports javafx.graphics/com.sun.javafx.tk=com.sampleapp, however, I'm not sure how to do this in gradle. I've tried adding it to the applicationDefaultJvmArgs, which didn't work.
application {
...
applicationDefaultJvmArgs = listOf(
"--add-exports javafx.graphics/com.sun.javafx.tk=com.sampleapp"
)
}
I've also tried adding it to gradle.properties.kts and it didn't work.
org.gradle.jvmargs = listOf(
"--add-exports javafx.graphics/com.sun.javafx.tk=com.sampleapp"
)
I was able to solve the issue by adding:
tasks.withType<JavaCompile> {
options.compilerArgs.addAll(arrayOf(
"--add-exports", "javafx.graphics/com.sun.javafx.tk=com.sampleapp"
))
}
Related
We have a multi-module project in gradle. We have a "data" module that needs to be compiled (simple java 11 app) then run.
When we run java -jar data.jar after compiling the data module source is generated into the "webapp" module. With this generated source code we are now able to build the webapp module.
I am new to Gradle and struggling to figure out how do achieve this properly. I am especially concerned if I do it wrong I will make build caching fail.
Note: I am using Kotlin with Gradle 7.5.
The answer appears to be to create a custom configuration which produces a different artifact than the default.
task(taskJarGenerated, Jar::class) {
group = groupJooq
dependsOn(taskCompileGeneratedSource)
inputs.dir("$projectDir/build/classes/java/main")
outputs.file("${projectDir}/build/libs/data-1.0.jar")
from("$projectDir/build/classes/java/main")
}
artifacts {
add("generatedDbDataJar", tasks[taskJarGenerated])
}
Then you can reference this custom configuration "generatedDbDataJar" in other projects like this:
dependencies {
implementation(project(":data","generatedDbDataJar"))
}
I'm trying to configure the Test task inside a custom Gradle plugin written in Java.
Applying the plugins I need like so in build.gradle.kts:
plugins {
`java-gradle-plugin`
`maven-publish`
}
I can compile the code successfully through the command line as in ./gradlew clean build
But, IntelliJ complains about Test.class in the following code:
public static void configureTesting(final Project project) {
project.getTasks().withType(Test.class).configureEach(task -> {
});
}
Saying:
Required type: java.lang.Class <S>
Provided: java.lang.Class <Test>
reason: no instance(s) of type variable(s) exist so that T conforms to Task
I import the Test class like this:
import org.gradle.api.tasks.testing.Test;
Gradle version: 6.7.1
IntelliJ: 2020.2.3
I spent some (a lot of) time googling this. Eventually I found a comment somewhere saying that one could try to use the internal SDK (jbr) that ships with IntelliJ instead of a manually downloaded SDK. That made it work. The internal SDK is Java 11 and I've also installed the latest version of Java 11 from Oracle. Even though they are both Java 11, the internal SDK (jbr) is working as it should, but not the external SDK. For other projects the external SDK is working fine, but not for building a Gradle plugin.
I'm trying to make my first app in Kotlin Native. I want to add TornadoFX to my freshly created project.
I need to add a dependency according to TornadoFX guide
dependencies {
compile 'no.tornado:tornadofx:x.y.z'
}
The issue is - I cant figure out where exactly do I put it.
This is my build.gradle contents (generated by IntelliJ IDEA):
plugins {
id 'org.jetbrains.kotlin.multiplatform' version '1.3.60'
}
repositories {
mavenCentral()
}
kotlin {
// For ARM, should be changed to iosArm32 or iosArm64
// For Linux, should be changed to e.g. linuxX64
// For MacOS, should be changed to e.g. macosX64
// For Windows, should be changed to e.g. mingwX64
mingwX64("mingw") {
binaries {
executable {
// Change to specify fully qualified name of your application's entry point:
entryPoint = 'sample.main'
// Specify command-line arguments, if necessary:
runTask?.args('')
}
}
}
sourceSets {
// Note: To enable common source sets please comment out 'kotlin.import.noCommonSourceSets' property
// in gradle.properties file and re-import your project in IDE.
mingwMain {
}
mingwTest {
}
}
}
// Use the following Gradle tasks to run your application:
// :runReleaseExecutableMingw - without debug symbols
// :runDebugExecutableMingw - with debug symbols
Places I tried:
1. top level
> Could not find method compile() for arguments [no.tornado:tornadofx:1.7.19] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
2. inside kotlin {}
> Could not find method compile() for arguments [no.tornado:tornadofx:1.7.19] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
3. inside mingwMain{}
> Could not find method compile() for arguments [no.tornado:tornadofx:1.7.19] on object of type org.jetbrains.kotlin.gradle.plugin.mpp.DefaultKotlinDependencyHandler.
Also, when put inside mingwMain, the compile line gets highlighted with a notice 'compile' cannot be applied to '(java.lang.String)'
For the Kotlin multiplatform plugin, the dependency block should go into each source set. However, there is no type called compile. Rather, you can use implementation or one of the other types which you can read about in the documentation.
Example:
sourceSets {
mingwMain {
dependencies {
implementation 'no.tornado:tornadofx:x.y.z'
}
}
}
BTW, why are you using the Groovy DSL and not the Kotlin DSL if you are writing a Kotlin project? :-)
As it was pointed out by this comment we cannot use TornadoFX in Kotlin Native, so I was doing everything wrong since the beginning, and this is not really a gradle issue.
I’m trying to use a Java, Serenity-BDD project with gradle version 4.8+, but the application is not pulling the CLI arguments of -Denvironment and -Dservicebranches. I have these properties as blank values in my local.properties file, and they’re not getting assigned when my app runs.
./gradlew --build-cache build -Dwebdriver.remote.url=${SELENIUM_REMOTE_URL} -Denvironment=${ENVIRONMENT} -Dservicebranches=${SERVICE_BRANCHES} -Dtags=${TAGS}
I have a local.properties file with properties that are being successfully dependency injected into the project (through Serenity-Spring). I'm hoping that these CLI arguments will override these values:
servicebranches=
environment=local
But right now, anything specified in the CLI arguments are not being passed into the project. Either through DI, or through explicitly grabbing the environment variables in the build.gradle, which what I've tried hasn't been working.
Here's a few things which I have tried in the build.gradle:
//task integrationTests() {
// doFirst
// {
// def environment = System.getProperty('environment')
// def servicebranches = System.getProperty('servicebranches')
// }
// tasks.build.execute()
//}
//integrationTests.dependsOn(build)
//build.doFirst{
// systemProperties System.properties
// def environment = System.properties['environment']
// environment = environment //This actually flags with 'Silly assignment'
//}
build.doFirst{
def environment = System.getProperty('environment')
def servicebranches = System.getProperty('servicebranches')
}
The latest one seems to still be missing a step, because the program is still working, but the args are still not getting through. I've even tried -Denvironment=potato, and no errors have come up because I do not have a property or properties file named that.
I've also tried using the -P tag instead of -D tag, but that doesn't seem to be working either.
All I’m trying to do is use build.gradle to use System.getProperty(‘environment’) and System.getProperty(‘servicebranches’) before I use the already created ‘build’ task that comes with Serenity. How would I do this? Do I build a whole new task, where I use these getProperties, and then call the build task? Do I have to specify the assignment of these same named variables in the local.properties file?
-D is for system properties in Gradle. Try with -P instead (https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties)
I know this is a very old question but here's what I did to solve my problem, I got the idea from here: https://github.com/serenity-bdd/serenity-documentation/pull/120/files
Serenity was not pulling the environment from gradle to use EnvironmentSpecificProperties, it kept saying "undefined property for environment 'null" when I removed the default environment. I had to add this to my Gradle file:
test {
systemProperty 'environment', System.properties['environment']
}
I have a simple use case of building an OSGi bundle using Gradle build tool. The build is successful if there are java files present in the build path, but it fails otherwise.
I am using 'osgi' plugin inside the gradle script and trying to build without any java files. The build always fails with following error:
Could not copy MANIFEST.MF to
I am sure there must be some way to do it in Gradle but not able to fine. Any idea what can be done to resolve this depending on your experience.
I ran into this today as well, and #Peter's fix didn't work for me (I hadn't applied the java plugin in the first place...). However, after hours of Googling I did find this thread, which helped me find the problem.
Basically, it seems that the error occurs (as Peter stated) when no class files are found in the jar - my guess is because the plugin then cannot scan the classes for package names on which to base all the Import and Export information.
My solution was to add the following to the manifest specification:
classesDir = theSourceSet.output.classesDir
classpath = theSourceSet.runtimeClasspath
In my actual build code, I loop over all source sets to create jar tasks for them, so then it looks like this:
sourceSets.each { ss ->
assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) {
from ss.output
into 'classes'
manifest = osgiManifest {
classesDir = ss.output.classesDir
classpath = ss.runtimeClasspath
// Other properties, like name and symbolicName, also set based on
// the name of the source set
}
baseName = ss.name
}
}
Running with --stacktrace indicates that the osgi plugin doesn't deal correctly with the case where both the osgi and the java plugins are applied, but no Java code is present. Removing the java plugin should solve the problem.
I had the same issue also when java code was present.
Adding these two lines to the osgiManifest closure fixed the problem:
classesDir = sourceSets.main.output.classesDir
classpath = sourceSets.main.runtimeClasspath
-- erik