Me and my team are working on a project with a lot of modules. We are using gradle for the project and everyone is new to gradle. We have a Main parent project i.e, parent build with the details of project dependencies. We want to add the integration_test task configuration to all the modules so that we can call the command gradle integration_test. So is there any way or concept of writing the configuration in the main module and make the child projects import the same configuration.
FYI: I tried it by directly adding it to the main project but got an error saying the classpath for the files which I specified does not exists. Any help or thought would be appreciated. Thanks in advance.
Is there a particular reason to split "integration tests" from the standard test task?
If so, you can run the same script for all subprojects from the main project's build file: https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:subproject_configuration
For instance:
subprojects {
task integrationTest {
// whatever you need
}
}
I am note sure if this is what you talk about in the last paragraph. If so, please attache the error message you get.
It is also possible to "import" some configuration by subprojects, but the above definition is better in most scenarios.
Related
I added a subproject to my gradle project and now whenever I execute the target check, it also runs the tests on my subproject.
I was hoping that I could run the check-task on the main project by specifying it as absolute task as
gradle :check
or
gradle ::check
but both commandlines still execute all tests.
Any idea?
There is no way around this, so you would need to restructure your build (I think check task of the parent is by definition a aggregate of the sub-projects). You can have sub-projects depending on each other, I assume that might be what you want to model in your build.
Let's assume you have the sub-projects core and myModule.
If you want myModule to depend on (and use the output of) core, you add a project dependency to myModule:
dependencies {
compile project(':core')
}
This will also setup the task dependencies correctly.
you can access the task-graph of a subproject from the main projects `build.gradle' and disable tasks.
This way you can disable the task when you call it on the main project, but it will still be enabled when you call the build file of the subproject directly:
project('subproject') {
//disable 'check' and 'test' task
gradle.taskGraph.whenReady {
tasks.find {it.name=="check"}.enabled=false
tasks.find {it.name=="test"}.enabled=false
}
}
Let's assume my build.gradle file contains task generateSources which as name suggests generates additional java files. It's easy to ensure that generateSources is executed before compileJava: compileJava.dependsOn generateSources. How can I make sure generateSources is called when importing project into Intellij Idea as well?
To elaborate on #vladimir-sitnikov's answer: I added the idea-ext-plugin to my root project:
apply plugin: 'org.jetbrains.gradle.plugin.idea-ext'
// ...
buildscript {
dependencies {
classpath "org.jetbrains.gradle.plugin.idea-ext:org.jetbrains.gradle.plugin.idea-ext.gradle.plugin:0.7"
}
}
Because without that I wasn't able to use it in my sub project, but now it works like this:
idea.project.settings.taskTriggers {
beforeSync tasks.getByName("generateSources")
}
Adding the plugin to the sub-project only didn't do it.
Note: The plugin's documentation is kind of limited, but in "DSL spec v. 0.2" is stated
beforeSync - before each Gradle project sync. Will NOT be executed on initial import
Didn't try that, but it works with existing projects.
This can be done via id("org.jetbrains.gradle.plugin.idea-ext") plugin (https://github.com/JetBrains/gradle-idea-ext-plugin).
See sample code in Gradle sources: https://github.com/gradle/gradle/blob/135fb4751faf2736c231636e8a2a92d47706a3b9/buildSrc/subprojects/ide/src/main/kotlin/org/gradle/gradlebuild/ide/IdePlugin.kt#L147
You can set the task in Gradle tool window: Execute Before Sync:
I'd like to create a subproject that acts as sole anchor for dependencies, ie. it includes no source code. Users can simply depend on the artifact created by the subproject in order to get all the required dependencies. So i've created foo-bar/build.gradle:
dependencies {
compile project(":foo-barz")
compile project(":foo-batz")
}
jar {
enabled = false
}
That seems to work as expected, until signing comes into the build process. I've then get an error message
:foo-bar:signArchives FAILED
What went wrong: Execution failed for task ':foo-bar:signArchives' >
java.io.FileNotFoundException:
/data/flo/code/foo/foo-bar/build/libs/foo-bar-4.0.1.jar (No such file
or directory)
How can I tell the signing plugin that it needs to sign just the pom file for this subproject?
I'd say either do not apply the java plugin, then you also don't need to disable the jar task, or also disable the signArchives task like you disabled the jar task.
I've came up with just creating an empty file with
foo-bar/src/main/java/org/foo/bar/FooBarDummy.java
so that all tasks are happy and an empty jar is created, signed and deployed. Thaks to Peter Niederwieser, Vampire and Daryl Teo for their input. I've found no elegant an easy solution to avoid that Dummy.java workaround.
This question was based on implementing smack-java7
It's easy to write a custom plugin and include it in the build script
apply from: "utilities.gradle"
For test purpose this file is in the same directory as the build.gradle
Calling a task defined in utilities.gradle from build.gradle works without any hassle.
In utilities gradle is also a plugin defined - configuring it from build.gradle just works.
But if I define a custom task in utilities.gradle calling it is no problem but if I want to use that custom taks in build.gradle it says
> Could not find property 'GreetingTask' on root project 'TestGradle'.
utilities.gradle:
task hello(type: GreetingTask)
class GreetingTask extends DefaultTask {
#TaskAction
def greet() {
println 'hello from GreetingTask'
}
}
build.gradle
task hellox(type: GreetingTask)
Ok... I read the documentation here: http://www.gradle.org/docs/current/userguide/custom_tasks.html
It says the custom task is not visible outside...
But then... how to share custom tasks with the team without making a Jar for everything.
What I want is to place the utilities.gradle on a network drive and share it with the other.
pls help
There is a special $rootDir/buildSrc directory which is its own build. All classes that this build produces are available to all build scripts in the "main" build. The buildSrc build has a default build.gradle, but you can add your own. By default, Java classes are expected under src/main/java, and Groovy classes under src/main/groovy. You can read more about buildSrc in the Gradle User Guide.
To share classes across multiple builds, a separate plugin project that publishes a Jar is the way to go.
I'm working on a project that uses EJB2s. The created EJB Jars require additional processing by the application server before they're bundled in the war/ear and deployed.
I have created a custom task that works to do the additional processing if I invoke it explicitly (gradle ejbDeploy), but am having trouble fitting it into the gradle multi-project lifecyle. I need to somehow add it to the build graph to execute automatically after the jar task.
My first attempt was to add it to jar with
jar.doLast{
ejbDeploy.execute()
}
which seems to work for arbitrary code blocks, but not for tasks
What's the recommended solution for this? I see three approaches:
Hook into the build graph and add it explicitly after the jar
task.
Set it up somehow in jar.doLast{}
Set it up as a prerequisite for the WAR task execution
Is there a recommended approach?
Thanks!
I would go for approach #3 and set it up as a dependency of the war task, e.g.:
war {
it.dependsOn ejbDeploy
...
}
I'm new to Gradle, but I would say the answer really depends on what you're trying to accomplish.
If you want to task to execute when someone runs the command gradle jar, then approach #3 won't be sufficient.
Here's what I did for something similar
classes {
doLast {
buildValdrConstraints.execute()
}
}
task buildValdrConstraints(type: JavaExec) {
main = 'com.github.valdr.cli.ValdrBeanValidation'
classpath = sourceSets.main.runtimeClasspath
args '-cf',valdrResourcePath + '/valdr-bean-validation.json'
}
Add the following, and then ejbDeploy will be executed right after jar, but before war
jar.finalizedBy ejbDeploy
See Gradle Docs. 18.11. Finalizer tasks