When I try to add a task to the main build task with the following code:
rootProject.tasks.getByName('build').dependsOn mytask
It complains when I run gradle(w) build with the output:
* Where:
Build file '...' line
: ...
* What went wrong:
A problem occurred evaluating project ':myapp'.
> Task with name 'build' not found in root project 'main'.
how do i add the task to the build task?
The problem is that your build has no build task, at least at the time when above line gets evaluated. Usually, the build task gets added by the java-base plugin, which in turns gets applied by plugins such as java, groovy, or scala. So make sure to apply one of these plugins first. Or, if you don't use any of them, declare your own build task.
Related
I have a multi-module gradle project with the following structure:
root_project
----sub-moduleA
--------build.gradle
----sub-moduleB
--------buld.gradle
----build.gradle
----settings.gradle
I would like to create a custom task on the 'build.gradle' file on the 'root_project' that allows me to execute a given action (lets say 'test') just on a given sub-module.
I know that I can do this from the command line, lets say execute the 'test' task on 'sub-moduleA':
gradle :sub-moduleA:test
Is it possible to create a custom task on the root_project build.gradle file to do this action?
i would like to run the build-task from the gradle war plugin inside one of my own defined tasks. I tried various things, but nothing worked.
This is how my task looks at the moment:
task deploy << {
build.execute()
copy {
from '/build/libs/app.war'
into tomcat_webapps
}
}
When i run
gradle deploy
the build task will not be executed. Does anyone of you know how i can do this?
Thank you!
Calling tasks manually should be your very last resort. The gradle way would be to define a dependency between your task and the build task. This way gradle can determine a proper order for the tasks that need to be executed.
Setting up the dependency can be done in several ways. One way would be this:
task deploy(type: Copy) {
dependsOn build
from '/build/libs/app.war'
into tomcat_webapps
}
I have a multi-project dependency in my gradle build, but there's a feature that's somewhat in my way. Whenever I call a task name that exists in both projects, it calls them both. I don't like that.
My directory structure is as follows:
[Root]
---->[projA]
----------->build.gradle
---->[projB]
----------->build.gradle
So I have projB dependent on projA in my code.
Say I have a task run in projB:
task run << {
println 'projB running'
}
And I also have a task run in projA:
task run << {
println 'projA running'
}
By calling gradle run, I would get
:run
projB running
:projA:run
projA running
Is there any way to prevent some of the tasks from having this dependency? Some of them, say clean is fine, but I'd prefer to have specific tasks separate (without having to change the naming scheme).
The equivalent of what I want can be achieved by doing either:
gradle run -x :projA:run
or
gradle :run
I want a solution that is within the build file, though.
Thanks!
That fact that projB declares a project dependency on projA is irrelevant for the behavior you are seeing. If you execute a task from the root project of a multi-project build Gradle will try to find the task in any of its subprojects with the requested name and execute it. This feature is called task execution matching. Given this default behavior there's no way Gradle could know which run task you mean when executing gradle run from the root project. I'd suggest you define what you want to execute on the command line as mentioned in my previous comment.
If you really wanted to add logic to your build script, then you could achieve it with the following code:
def taskRequests = gradle.startParameter.taskRequests
def runTaskRequest = taskRequests.find { it.args.contains('run') }
if (runTaskRequest) {
gradle.startParameter.excludedTaskNames = [':projA:run']
}
The code provided would prevent the execution of the run task for the subproject projA if you execute the command gradle run. Keep in mind that it would also exclude :projA:run if you navigate to the projA subdirectory and run the same command. If you still want to be able to execute the run task from the subdirectory, then you'll have to build in additional logic.
I'm rather baffled on this. If I pass in this version number, gradle fails:
gradle -Pversion=120151021 build
:eventing:compileJava
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':eventing:compile'.
> Could not find eventing-test.jar
I've no idea why it thinks it needs to find eventing-test.jar. That's the name I have it creating for the jar of test classes. Seems like a red herring of a message.
If I simply put ANY alpha character in front of the version string, it works:
gradle -Pversion=z120151021 build
:eventing:compileJava
:eventing:processResources UP-TO-DATE
:eventing:classes
etc
etc
It seems to be a problem if it just starts with numbers:
gradle -Pversion=11abc build
:eventing:compileJava
FAILURE: Build failed with an exception.
Though, in a truly bizarre turn, it's ok if it starts with a single "1":
gradle -Pversion=1abc build
I don't see anything in the Gradle documentation that says a numeric version number is a problem.
I still don't know why the original setup didn't work, but I worked around it as follows. Inside each jar and publish target, I specifically pulled in another variable as the version. For example.
task testJar(type: Jar) {
from sourceSets.test.output
version = System.getProperty('RELEASE_VERSION', "unversioned")
appendix="test"
}
jar {
version = System.getProperty('RELEASE_VERSION', "unversioned")
}
Note, it does NOT work to do this trick to set version at the outer gradle level. It results in the same error I had before.
Does not work:
apply plugin: 'application'
version = System.getProperty('RELEASE_VERSION', "unversioned")
...define tasks and such that would use "version" ...
I am working on Java/JNI project. Under parent, I have different modules for java and C codebase.Java module needs to generate JNI header file. Since, I couldn't find any existing task/plugin that supported javah, so I wrote my custom task for javah to generate JNI interface. So, when I do
gradle javah
I am getting the desired output.
However, I want that whenever I invoke gradle build, it should also execute javah task once either after classes are generated or build task ends.
Also, is it possible to generate the shared libraries in such a mixed project when I just do gradle build? Currently, I have to do gradle <project-name>SharedLibrary
Part 1: You can use finalizedBy on task1 to execute task2 after task1 completes. For your case, you can try the following:
// 'javah' will be executed after 'classes' task executes.
classes.finalizedBy javah
// Make 'javah' task depend on 'classes' task,
// so that when 'classes' task fails, 'javah' is not executed.
javah.dependsOn classes
// Make 'build' depend on 'javah' task,
// so that executing 'build' task automatically executes 'javah'
build.dependsOn javah
Part 2: You can use dependsOn to wire up the <project-name>SharedLibrary task as follows:
build.dependsOn "${project.name}SharedLibrary"
// Assuming the SharedLibrary task needs to depend on 'javah' task
tasks["${project.name}SharedLibrary"].dependsOn javah
I'm assuming that the the SharedLibarary task name is dynamic, hence using a slightly different syntax for that task.