In Gradle multi-module project, how to tell Gradle child module not to build any libs/jars and other dependencies ? Is there some alternatives to maven <packaging>pom in Gradle?
So as a result i can specify jar.enabled = false and module will not produce any artifacts, however you can still perform custom tasks like compile/copy in this module.
Related
I have a multi-module Gradle project with n subprojects written in Java, and one non-Java web subproject, as follows:
parent
- service1
.
.
- serviceN
- web
In my parent build.gradle, I define plugins as follows:
plugins {
id: 'whatever'
}
In my all of my subprojects except one, I want use the whatever plugin. But in my web subproject, I want to exclude the whatever plugin since that subproject is not written in Java. How do I skip a plugin in a subproject?
In Maven, I can do this by redefining the plugin in the <plugins> section of the module's pom and setting the <skip> tag to true.
How do I do something similar to this in the latest version of Gradle (at time of writing, 7.4.2)? Note that I want to configure whether the plugin is skipped in the child subproject, not in the parent project.
In Gradle subprojects, a plugin declared in the plugins block in the parent's build.gradle can be disabled/skipped in the child by adding apply false to the child project's build.gradle plugins configuration. In this case, that would look like:
plugins {
id 'whatever' apply false
}
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 am building a plugin in IntelliJ and Gradle, and have the following question:
What is the difference between the predefined tasks build and buildSearchableOptions in Gradle?
I can see that :buildSearchableOptions is called as part of :build and that it produces its own JAR file.
They come from two different plugins.
Assuming a Java project, the build task comes from the java plugin which in turn comes from the life cycle/base plugin:
https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/JavaBasePlugin.java#L74
https://docs.gradle.org/current/userguide/base_plugin.html
The buildSearchableOptions task comes from the org.jetbrains.intellij plugin:
https://github.com/JetBrains/gradle-intellij-plugin/blob/master/src/main/groovy/org/jetbrains/intellij/IntelliJPlugin.groovy#L350..L360
https://github.com/JetBrains/gradle-intellij-plugin#tasks
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 apply my custom plugin to project:
plugins {
id 'my.plugin.gradle-plugin' version '1.0.0'
}
This plugin contains task runMe and I want to always execute it only with build task.
The way to get it specifying in my root project:
build.dependsOn runMe
But I want to get this behavior by setting up the plugin once and don't repeat this every project which uses the plugin.
What you can do is to check in apply method if build task already exists. If so you can define a dependency there. Otherwise it's impossible.
Also, where does the build task come from? Another plugin? If so apply this plugin in you plugin and then define the dependency.