I'm going through some simple Gradle examples, and trying to get my head around the syntax. According to Gradle syntax, there must be a method called 'main' somewhere on 'sourceSets' (which is a SourceSetContainer) that takes a Closure. I figured that I would be able to find it by browsing around the Gradle javadocs, but I can't find it. Can someone point me to where 'main' is defined in this example?
apply plugin: 'java'
sourceSets {
main {
java {
srcDirs = ['src']
}
}
}
sourceSets is a container of named source sets. The java plugin adds a source set named main (and another named test) to that container. As such, there is no physical method or property called main. sourceSets.main { ... } could also be written as sourceSets.getByName("main") { ... }.
Related
i'm currently setting up a new project using java, gradle and spring boot. I'm struggling to create my planned test setup. My goal is to have separate test commands and directories located IN the test package.
What I have
I have looked into gradle sourceSets and was able to create two new sourceSets for unit and component tests. The problem I face is that I don't know if there is any way to defined the path of the sourcesets so they are inside the test directory.
src
-- main
-- test
-- unit
-- component
What I want
I just want the default test sourceSet to behave like a normal directory which itself contains my two testing sourceSets like this:
src
-- main
-- test
---- unit
---- component
Is this possible and also would this be 'against the convention' or something like that?
Any pointers are appreciated!
Basically, you should be able to set paths to your source sets any way you want to. Something like this should work:
sourceSets {
test {
java {
srcDirs = ['test/unit']
}
resources {
srcDirs = ['test/unit']
}
}
testComponent {
java {
srcDirs = ['test/component']
}
resources {
srcDirs = ['test/component']
}
}
}
Unfortunately I'm not sure if you can change the names of default source sets.
Keep in mind that you will have to provide more configuration for your new source set, e.g. create new Test task:
task testComponent(type: Test) {
testClassesDirs = sourceSets.testComponent.output
classpath += sourceSets.main.output
}
And also manage its dependencies separately or extend them from already existing configuration:
configurations {
testComponentCompile.extendsFrom(testCompile)
testComponentRuntime.extendsFrom(testRuntime)
}
As for the convention: it's best to stick to provided defaults, but if you have the need for different structure then it's also fine. Most common case for test separation is probably when you want split unit and integration test in order to be able to run them individually.
I know how to ignore classes defined in their own .java files, but not aware of how to ignore inner classes.
For example, I have class A with nested class B:
class A {
...
static class B {
...
}
}
jacocoTestReport keeps checking the coverage when I want to ignore them in jacoco.gradle file with this syntax(learned from this post: How to ignore inner/nested classes with JaCoCo?): (setFrom part is for later versions of Gradle, where classDirectories = files() is deprecated)
apply plugin: "jacoco"
jacoco {
toolVersion = "0.8.3"
}
jacocoTestReport {
afterEvaluate {
classDirectories.setFrom(files(classDirectories.files.collect {
fileTree(dir: it,
exclude: [
"com/example/xxx/*",
"com/example/xxx/A\$.*B*"
])
}))
}
}
($ must be escaped, while in the post there is no need because he uses Maven when I use Gradle)
So, how can I ignore this inner class?
At last I found the answer with several trial-and-failure. Seems that the naming pattern follows compiled Java classes naming convention, as mentioned in the other post, and will not require the . between the outer class and the inner class. So, it should be like A$B. And, there may be some .class interfering(my guess), so I added A$B*(for other normal classes, last * is not needed).
So it becomes:
"com/example/xxx/A\$B*"
I hope there be some documentation about this pattern of exclusion. There is not, yet.
We're making Dagger module for providing class as follows, but we encounter the problem.
CustomHelper is *.kt class, if we use CustomHelper::class into #ClassKey, it won't be recognized in Java and get syntax error.
Even if we change to use CustomHelper.class as follows, we still get compile error.
#Provides
#IntoMap
#ClassKey(CustomHelper.class) // <- not work
static Helper provideCustomHelper(CustomHelper customHelper) {
return customHelper;
}
We will appreciate any help.
Check your module build.gradle. Maybe you forget to add apply plugin: 'kotlin-android' in top of build.gradle.
For using Kotlin class you need to swap it to java class using javaClass method as in
#Provides
#IntoMap
#ClassKey(javaClass<CustomHelper>()) // <- not work
static Helper provideCustomHelper(CustomHelper customHelper) {
return customHelper;
}
I want to write custom Lombok Annotation handlers. I know http://notatube.blogspot.de/2010/12/project-lombok-creating-custom.html. But the current lombok jar file does not contain many .class files, but files named .SCL.lombok instead.
I found, the .SCL.lombok files are the .class files, the build script of Lombok does rename them while generating the jar file, and the ShadowClassLoader is capable of loading these classes -- and the acronym SCL seems to come from this. It seems the reason for this is just to "Avoid contaminating the namespace of any project using an SCL-based jar. Autocompleters in IDEs will NOT suggest anything other than actual public API."
I was only able to compile my custom handler by
unpacking the contents of the lombok.jar
renaming the .SCL.lombok files to .class
adding the resulting directory to the compile classpath
In addition, to be able to use my custom handler, I needed to create a new fat jar containing both the lombok classes and my custom handler. The custom lombok class loader essentially prevents adding custom handlers in other multiple jars.
Is this the only way to extend Lombok? Or am I missing something?
I am using the following buildscript
apply plugin: 'java'
repositories {
jcenter()
}
configurations {
lombok
compileOnly
}
def unpackedAndRenamedLombokDir = file("$buildDir/lombok")
task unpackAndRenameLombok {
inputs.files configurations.lombok
outputs.dir unpackedAndRenamedLombokDir
doFirst {
mkdir unpackedAndRenamedLombokDir
delete unpackedAndRenamedLombokDir.listFiles()
}
doLast {
copy {
from zipTree(configurations.lombok.singleFile)
into unpackedAndRenamedLombokDir
rename "(.*)[.]SCL[.]lombok", '$1.class'
}
}
}
sourceSets {
main {
compileClasspath += configurations.compileOnly
output.dir(unpackedAndRenamedLombokDir, builtBy: unpackAndRenameLombok)
}
}
tasks.compileJava {
dependsOn unpackAndRenameLombok
}
dependencies {
compile files("${System.properties['java.home']}/../lib/tools.jar")
compile "org.eclipse.jdt:org.eclipse.jdt.core:3.10.0"
compile 'javax.inject:javax.inject:1'
lombok 'org.projectlombok:lombok:1.16.6'
compileOnly files(unpackedAndRenamedLombokDir)
}
In the meantime Reinier Zwitserloot created a new git-branch sclExpansionUpdate, that contains an updated version of the ShadowClassLoader:
ShadowClassLoader is now friendlier to trying to extend lombok.
Your (separate) jar/dir should have a file named
META-INF/ShadowClassLoader. This file should contain the string
'lombok'. If you have that, any classes in that jar/dir will be loaded
in the same space as lombok classes. You can also rename the class
files to .SCL.lombok to avoid other loaders from finding them.
I guess this did not yet make it into the main branch because it certainly has not been tested that much - I just tried it out for myself and it contains a little bug that prevents loading the required META-INF/services from extensions. To fix it you should replace two method calls to partOfShadow with inOwnBase:
[... line 443]
Enumeration<URL> sec = super.getResources(name);
while (sec.hasMoreElements()) {
URL item = sec.nextElement();
if (!inOwnBase(item, name)) vector.add(item); // <<-- HERE
}
if (altName != null) {
Enumeration<URL> tern = super.getResources(altName);
while (tern.hasMoreElements()) {
URL item = tern.nextElement();
if (!inOwnBase(item, altName)) vector.add(item); // <<-- AND HERE
}
}
I tested it with the above fix and it seems to work fine (not tested much though).
On a side note: with this new extension mechanism, it is now finally also possible to have the extensions annotation handlers and annotations in a different namespace than "lombok" - nice!
Using the input from this question and from the other answer (by Balder), we managed to put together a custom Lombok annotation handler: Symbok. Feel free to use that as a sample for writing your own.
BTW, instead of writing a custom Lombok handler, you could also implement a javac plugin instead -- it might be simpler.
My project has both Java (N files) and Groovy code (1 file only). Java compile depends upon this single Groovy file's class file for Java compilation (compileJava task to succeed).
When I don't use src/java as one of the srcDir within main>groovy> sourceSet section, then I get an error saying class/symbol not found which is in the groovy file/class. In ANT, it's easy that we are calling compile-groovy target first, before calling compile-java target but the same in Gradle is what I'm trying to find.
I read some posts and found that if I make main>java section NULL and specify srcDir for main>java which is src/java inside main>groovy sourceSet section, then it compiles fine.
My ?s:
1. Is there any other way to do? for ex, the following should work:
compileJava {
dependsOn compileGroovy
}
though, this goes to an infinte loop.
OR
what about using doFirst for compileJava task:
compileJava {
doFirst {
compileGroovy
}
}
this doesn't work either.
build.gradle This works, but compileJava in one sense becomes useless here even though the source code has N no. of java files in the src/java or src/java-test etc tree. I know this build script is working but logically it might bring some confusion to the developer if s/he is not familiar why sourceSet for Groovy MUST have "src/java" as its srcDir value.
apply plugin: 'java'
apply plugin: 'groovy'
sourceSets {
main {
groovy {
srcDir 'src/groovy'
srcDir 'src/java'
}
java {
//The following needs to be commented out OR Gradle will always pick compileJava before compileGroovy
//srcDir 'src/java'
//srcDir 'src/java-test'
}
}
test {
groovy {
srcDir 'test/groovy'
}
java {
srcDir 'test/java'
}
resources {
srcDir 'test/resources'
srcDir 'conf'
}
}
integrationTest {
groovy {
srcDir 'src/groovy-test'
}
java {
srcDir 'src/java-test'
}
resources {
srcDir 'test/resources'
srcDir 'conf'
}
}
}
Other links:
How to make Gradle compile Groovy tests before Java tests
The Groovy (base) plugin makes GroovyCompile tasks depend on the corresponding JavaCompile tasks because it's more common to call from Groovy into Java than the other way around. If you need it the other way around (or both ways), joint compilation is a good solution. Here is a somewhat improved (over your version) joint compilation setup:
sourceSets {
main {
groovy {
// override the default locations, rather than adding additional ones
srcDirs = ['src/groovy', 'src/java']
}
java {
srcDirs = [] // don't compile Java code twice
}
}
}
If you prefer separate compilation with Java->Groovy dependencies only, something like the following should work:
// since you aren't using the default locations
sourceSets {
main {
groovy {
srcDirs = ['src/groovy']
}
java {
srcDirs = ['src/java']
}
}
}
// remove GroovyCompile->JavaCompile task dependencies
tasks.withType(GroovyCompile) {
dependsOn = []
}
// add JavaCompile->GroovyCompile task dependencies
tasks.withType(JavaCompile) { task ->
dependsOn task.name.replace("Java", "Groovy")
}
Because a JavaCompile task and its corresponding GroovyCompile task write to the same output directory, Java compilation will now have the compiled Groovy code on its compile class path.
PS: Calling a task from another task is not supported, and bad things can happen if you try. Instead, you should always work with task relationships (dependsOn, finalizedBy, mustRunAfter, shouldRunAfter).