I want to get the directory of Java files in a Groovy plugin.
For example, I have a Java file in a directory:
"/gradleProject/src/main/java/com/file.java"
How can I get:
"src/main/java"
In Maven there is Build.getSourceDirectory(), what is the equivalent in Gradle?
Further to Rene's answer, the groovy DSL makes it easy to get the SourceSet
SourceSet mainSourceSet = project.sourceSets.main
In java this is a little bit more verbose
SourceSet mainSourceSet = project.getConvention().getPlugin(JavaPluginConvention.class).getSourceSets().getByName("main");
In Gradle, those source folders are managed by SourceSets, that are brought to you by the Java plugin. The java plugin adds two sourceSets named main and test.
once the java plugin is applied, you can access those sourceSets and their properties (e.g. the folders you're looking) simply by name: project.sourceSets.main.srcDirs - this will give you all the configured source directories for the main sourceSet in your project.
The latest way to do this, using the Kotlin DSL:
val javaExt = project.extensions.getByType(JavaPluginExtension::class.java)
val mainJavaSource = javaExt.sourceSets.getByName(SourceSet.MAIN_SOURCE_SET_NAME)
Using the Kotlin DSL (Gradle 7.5)
tasks.register<JacocoReport>("jacocoTestReport") {
dependsOn("testDebugUnitTest")
val sourceSets = project.extensions.getByType<KotlinProjectExtension>().sourceSets
sourceDirectories.setFrom(sourceSets)
}
Note that besides the JavaPluginExtension there is also a KotlinAndroidProjectExtension, so you may can get rid of the Android Gradle Plugin in your community plugins.
Related
My project started with a single build.gradle (no multi-project). The project has src/test/java and src/test/kotlin folders.
So far, I have applied the configuration for both projects.
Main problem is the incompatibility with JDK 9 for java submodule and JDK 8 for kotlin submodule. With this error message
Could not target platform: 'Java SE 9' using tool chain: 'JDK 8 (1.8)'.
I want to apply:
only to src/test/java a specific config (sourceCompatibility = 1.9)
same to src/test/kotlin this config (kotlinOptions.jvmTarget = "1.8")
How can I split both folders (java and kotlin) into submodules without moving files ? The folders don't have to be split as submodules. I only want to apply different compilations options.
The project build.gradle is there
Use sourceSets
sourceSets {
test {
kotlin {
srcDirs = ["src/test/kotlin"]
}
java {
srcDirs = ["src/test/java"]
}
}
}
I found an answer how to run in IntelliJ, https://stackoverflow.com/a/58796344/311420
Basically, I was trying to use gradle configuration to run. But the tests fail in Intellij but not in gradle.
Now I run the tests with IntelliJ configurations not gradle.
It is half satisfactory answer.
You can see how my tests in Circle CI and Travis CI
We have a Gradle project with a bunch of modules. One of those modules is a custom code generator, written as a Gradle plugin. We want to run that code-generator plugin in another module later in the same overall multi-module build, in order to test the code generator.
We know how to create a separate project on the fly and run the code generator in that, but we need to run the code generator in the main project, not in a temporary test project.
Nothing we have tried works, and the Gradle documentation doesn't appear to address this. It seems to be fundamental to Gradle's design, because the entire set of plugins used in a build is basically a single program, assembled at the start. Trying to add a just-now-built plugin after the fact seems unsupported, or we're missing something.
The best we've been able to come up with so far is to implement the plugin in Java (Kotlin would also have worked), so the Gradle plugin is just a thin Gradle skin over the implementation, and call the Java implementation directly when running the code generator in the other module. This works, but it means we aren't actually testing the Gradle portion of the code generator.
This is natively supported in Maven (maven multi-module project with one plugin module, and https://maven.apache.org/guides/mini/guide-multiple-modules.html), which is not surprising because every plugin in Maven runs in a separate class loader. If it's not possible in Gradle, that would be one of the few cases where Gradle doesn't have feature parity.
A hacky way to do this is to run the newly-compiled plugin via Gradle's test kit runner.
A cleaner way to do this is to write plugins as thin shells of code written to Gradle's API that delegate the real work to plain old Java (or Kotlin) utility methods. This has a number of advantages:
You can unit test the utility methods.
You can use the utility methods for other purposes unrelated to the plugin.
You can call the utility methods directly from other modules in the project, thereby accomplishing what the plugin would have done if you could have built it and then called it in the same build.
To expand on the above answer.
Instead of calling the plugin like a plugin, add a main method that accepts the same parameters that Gradle plugin configuration passed to the plugin.
Then call the plugin's main using Gradle's Java exec task:
task(generateFoo, type: JavaExec) {
main = 'com.bar.Foo'
classpath = configurations.runtimeClasspath
args = ["arg1", "${projectDir}/src/generated/java"]
}
Note the args: those are the same pieces of information that used to be passed in via Gradle configuration:
apply plugin: 'foo-plugin'
generateFoo {
theArg "arg1"
outputDir "${projectDir}/src/generated/java"
}
Because the runtime classpath used by Java exec is the one for the calling module, you may encounter runtime classloader problems.
If that happens, it's easily fixed. Just change the rewritten plugin to a fat jar:
task fatJar(type: Jar) {
manifest {
attributes 'Implementation-Title': 'Foo Fat JAR', 'Main-Class': 'com.bar.Foo'
}
baseName = project.name + '-exec'
from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
with jar
}
artifacts {
archives fatJar
}
And then execute the fat jar with Java exec:
def fooGenerate = task(generateFoo, type: JavaExec) {
main = 'com.bar.Foo'
classpath = files("${projectDir}/../foo-plugin-module/build/libs/foo-plugin-module-exec.jar")
args = ["arg1", "${projectDir}/src/generated/java"]
}
Finally, make the dependent module's compile task depend on the code generation:
compileJava.mustRunAfter fooGenerate
If you use the fatJar approach, you don't even need to declare implementation project(":foo") in the dependent modules.
It might be also be possible to use Gradle's composite builds for this (https://docs.gradle.org/current/userguide/composite_builds.html).
I have gradle project with Kotlin plugin.
In my project I uses groovy and Spock for tests.
One of utility classes used in tests in written in Kotlin and I put it to src/test/kotlin
I'm trying to use this class from groovy tests (Spock specification), I see that "compileTestKotlin" task runs first and compiles my utility class, but still "compileTestGroovy" fails, because it does not see it.
How can I fix this situation?
How to add build/classes/kotlin/test/ to the compilation classpath of groovy tests?
The issue is that by default compileTestGroovy doesn't include build/classes/kotlin/test folder, so your Kotlin util class cannot be seen from Groovy tests.
In order to fix it you can manually add Kotlin test sources to compileTestGroovy's classpath. Add the following to your build.gradle:
compileTestGroovy.classpath += files(compileTestKotlin.destinationDir)
// in more recent versions it must be
compileTestGroovy.classpath += files(compileTestKotlin.destinationDirectory)
If your build file is build.gradle.kts, add the following
// make groovy test code depend on kotlin test code
tasks.named<GroovyCompile>("compileTestGroovy") {
classpath += files(tasks.compileTestKotlin)
}
I have a java project to which I build it using gradle build and generate a war file.
Currently my requirement is to generate WSDL file at the time of build from java classes. I came to know about axis2-java2wsdl-maven-plugin and found the syntax of applying it in gradle. But I am not able to get the tasks list or the example of using this plugin in gradle to generate the WSDL file using this plugin.
Can anybody let me know of how to use this plugin or any other help so that I can generate WSDL file form my java classes.
Dependency section which I included in build.gradle:
repositories {
mavenCentral()
}
dependencies {
'org.apache.axis2:axis2-java2wsdl-maven-plugin:1.6.2'
}
axis2-java2wsdl-maven-plugin is a maven plugin not a gradle one.
Moreoever, gradle plugins must be defined in a buildscript closure or a plugins one if you want to use the new plugins DSL.
Here, you are just using the maven plugin as a regular dependency for your project.
As far as i know, there is not "java2wsdl" gradle plugin.
I have a gradle 4.1 multiproject containing a "projectA" containing 2 subfolders "api" and "implementation".
The multiproject uses kotlin and java-library plugins defined in the subprojects section of the main build.gradle.
The implementation project avec a API dependency to :projectA:api
In the api folder I have kotlin and java files inside 'src/main/java' and in the implementation project I'm creating a new instance of a kotlin class from the API.
Inside Intellij Idea, I don't have any compilation errors ; but when I compile the whole project using gradle I have an error: cannot find symbol. It is as if the compileJava doesn't have access to the folder kotlin-classes.
Inside the build/kotlin-classes, I see my file.class
The class file is on build/classes dir also
Details of the error :
Task :projectA:api:compileKotlin
Using kotlin incremental compilation
Task :projectA:implementation:compileJava
(...) error: cannot find symbol (the import fails)
Update 1 : removing java-library solved my problem
This is a known issue of the java-library plugin: when used in a project with another JVM language (Kotlin, Scala, Groovy etc.) , it does not register the classes of the other language so that the dependent projects get them as they consume the classes.
Fortunately, it has a workaround as well. Adapted to Kotlin, it would look like:
configurations {
apiElements {
outgoing.variants.getByName('classes').artifact(
file: compileKotlin.destinationDir,
type: ArtifactTypeDefinition.JVM_CLASS_DIRECTORY,
builtBy: compileKotlin)
}
}
If you use Kapt1, it's file: compileKotlinAfterJava.destinationDir, and for Gradle versions lower than 4.0 use builtBy: copyMainKotlinClasses instead.
This issue is also tracked in the Kotlin issue tracker: KT-18497, follow that issue to see when it's fixed on the Kotlin Gradle plugin side, so that the above workaround will be no more necessary.