While using kotlin with gradle, compileKotlin executes before compileJava. I need to execute compileJava before compileKotlin. I tried compileKotlin.dependsOn(compileJava) but it gives the Circular dependency build failure.
I also tried
compileJava.dependsOn = compileJava.taskDependencies.values - compileKotlin
But, it still executes compileKotlin before compileJava.
How can I execute compileJava before compileKotlin?
I faced the same problem in a spike test with gradle, Java, Kotlin, Scala and Groovy all together - not a real scenario, I recognize it!, but noticed that (by default, i.e. without any explicit configuration)
compileJava dependsOn compileKotlin
compileScala dependsOn compileJava
compileGroovy dependsOn compileJava
This limits my choices about the order which I can build my sources in: Java compilation can't happen before Kotlin compilation, as you told, and by converse Groovy and Scala compilation can't happen before Java compilation (which was my initial goal).
My idea is that the simplest wat to get the desired result is to split my source code into four different projects, setting up a multi-module project: this way I can move the problem from defining task dependencies (which as seen I can't control) to defining module dependencies (which I can control very simple through plan dependency management using something like compile project(':my-dependend-on-project') in my dependant project's build.gradle).
This is a very old question, so I suppose you already found a solution; anyway, I'm interested in your opinion about my conclusions about this topic.
Related
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).
Based on documentation (4.7.6 - Getting the insight into a particular dependency) we can get the insights for a particular configuration specifying the configuration itself.
In the example they are using as configuration compile, which is deprecated.
I tried to reproduce the same command replacing, in build.gradle, the compile configuration with the implementation configuration (as I got we are not supposed to use compile anymore).
But when I run:
gradle dependencyInsight --dependency groovy --configuration implementation
Gradle is returning:
Execution failed for task ':dependencyInsight'.
Resolving configuration 'implementation' directly is not allowed
My build.gradle file is the following:
apply plugin: 'java-library'
repositories {
jcenter()
}
dependencies{
implementation 'org.codehaus.groovy:groovy-all:2.4.10'
}
Does it mean I cannot get the insight of a dependency if I'm using implementation or is there another way to get it?
I had a similar problem, asked around and got this answer:
The configuration is compileClasspath. If you have variants, there is a configuration per-variant (e.g. for the release variant, your configuration would be releaseCompileClasspath).
Examples
No variants: gradle dependencyInsight --dependency groovy --configuration compileClasspath;
Release variant: gradle dependencyInsight --dependency groovy --configuration releaseCompileClasspath
Note
There are a few ways to figure out the available configurations.
If you add configurations.each { println it.name } to your top-level gradle file, the next time you run a task, you'll also get a list of all of your configurations.
Run the dependencies task on your top-level module - this will output all dependencies for all configurations. It can be a lot of text, so you could pipe it into a text file for easier searching (gradle dependencies > dependencies.txt)
To get the list of available configuration that can be used with dependencyInsight, the easy way is the following :
Open gradle view in android studio View > Tool Windows > Gradle
Select and run task 'Your App' > Tasks > Android > androidDependencies
Then you have a list of all dependencies for all available configuration, just pick one and run :
gradle :mymodule:dependencyInsight --dependency okhttp --configuration flavourDebugCompileClasspath
Hope it helps
I am trying out Gradle, and am wondering, what is supposed to happen to a project's dependencies after you run gradle build? For example, my sample projects don't run on the command line after they are built, because they are missing dependencies. They seem to compile fine, as gradle doesn't give me errors or warnings about finding the dependencies.
Gradle projects I've made in IntelliJ Idea have the same problem. They compile and run inside the IDE, but are missing dependencies and can't run on the command line.
So what is supposed to happen to the dependencies I declare in the build.gradle file? Shouldn't they be output somewhere together with my .class files? Otherwise, what is the point of gradle when I could manage this by editing my classpath?
Edit: Here is my build.gradle file:
apply plugin: 'java'
jar {
manifest {
attributes('Main-Class': 'Animals')
}
}
repositories {
flatDir{
dirs "D:\\libs\\gradleRepo"
}
}
dependencies {
compile name: "AnimalTypes-1.0-SNAPSHOT"
}
sourceSets{
main{
java {
srcDirs=['src']
}
}
}
Your Gradle build only takes care of the compile time and allows you to use the specified dependencies in your code (it adds them to the compile classpath). But it does not take care of the runtime. Once the JAR is build, you need to specify the runtime classpath and provide all required dependencies.
You may think, that this is bad or a disadvantage, but actually it is totally fine and intended, because if you build a Java library, you won't need to execute it, you just want to specify it as a dependency for another project. If you would distribute your library to a Maven repository, all dependencies from Maven repositories (module dependencies) would end up in a POM descriptor as transitive dependencies.
Now, if you want to build a runnable Java application, simply use the Gradle Application Plugin (apply plugin: 'application'), which will create a ZIP file containing the dependencies and start scripts providing your runtime classpath for execution.
Third-party plugins can also produce so-called fat JARs, which are JAR files with all dependencies included. It depends on your use case if you should use them, because often dependency management via repositories is the better way to go.
in my simple gradle build I would like to use ShadowJar and ProGuard together. I have found examples where the output of the shadowJar task is the input of the proguard one, which works fine, however in my case I would prefer first creating the small obfuscated jar first where I nicely specify the library dependencies and get proguard to focus only on my code and then I would like to pass that to the shadowjar plugin for fatjar packaging.
My setup is the following:
task obfuscate(type: proguard.gradle.ProGuardTask) {
injars jar
outjars "build/libs/foo-${project.version}-pg.jar"
...
}
shadowJar {
from obfuscate
configurations = [project.configurations.embed]
}
shadowJar.dependsOn obfuscate
And my problem is that the shadowJar output contains all the libraries unobfuscated (fine), my obfuscated code (fine) and my unobfuscated code. So somehow the original classes sneak in and I am not seeing how is that happening. I am not able to specify to shadowJar to package the dependencies and the proguard output jar together.
Do you see where is the problem in my approach?
Try this, works for me:
task shadowJar2( type: com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar ) {
baseName = jar.baseName
from obfuscate
configurations = [project.configurations.embed]
classifier = 'shadow'
//version =
}
The problem is that the default shadowJar task takes your 'main' sourceset in addition to the obfuscated + library jars. By defining your own custom 'shadowJar2' task, you are explicitly defining your sources, which in this case is only jars ('obfuscate' + 'embed') and not a sourceset.
It's configured the same here as it is everywhere else. In fact I use an import for configuring integration tests. I've done everything I can think of including a rename of local integration test tasks and configurations, including looking at the dependency tree, including running with --debug. Yet for some reason Gradle insists that the property integrationTest doesn't exist on the sourceSet for an inter-project dependency:
integrationTestCompile project(':components:things-components:abc-stuff').sourceSets.integrationTest.output
...now I'm not particularly fond of this syntax and I've already griped up a storm about inter-project test dependencies and how they should be in a test utility component. However, I'm doing it this way because this appears to be what IntelliJ will accept. Writing like this causes trouble:
integrationTestCompile project(path: ':components:things-components:abc-stuff', configuration: 'integrationTest')
How can I figure this out? I just don't get why only one project has this issue.
For the record, I've also tried:
integrationTestCompile project(path: ':components:things-components:abc-stuff', configuration: 'integrationTestCompile')
The issue is that Gradle hasn't been told to make a jar for you that you can consume in your other project.
integrationTestCompile project(':components:things-components:abc-stuff').sourceSets.integrationTest.output
Gets the classFiles and the dependencies, thats why its working using that notation. If you want to use the configuration notation you will need to tell gradle to publish a jar on the integrationTest. The jar doesn't have to be published to a repository, but will be used for the internal builds.
You can do this by doing:
configurations {
integrationTest
}
task integrationTestJar (type: Jar) {
baseName = "${project.name}-integ-test"
from sourceSets.integrationTest.output
}
artifacts {
integrationTest integrationTestJar
}
If you end up doing this in a log of projects, I would recommend writing a quick plugin that does this for you.