findByName() method returns null for gradle plugin task - gradle

I am using maven-publish plugin. I have a publication called myMedia. When I try executing
tasks.findByName("publishMyMediaPublicationToSnapshotRepository"), it returns null. Why does it return null if there is a task by that name that maven-publish plugin created.
I'm not able to get around this issue. Any help is greatly appreciated.
EDIT 1 : START
I tried Francisco Mateo's suggestion to use the afterEvaluate method, but this too didn't seem to work for me.
However, while trying to figure out the actual cause I came across one interesting observation. I found that the when I call tasks.findByName("publishMyMediaPublicationToSnapshotRepository") from within a task, then it works perfectly fine and prints out the task, i.e. printTaskName runs as expected :
task printTaskName{
doLast{
println "task name found is :--- "+tasks.findByName("publishMyMediaPublicationToSnapshotRepository")
}
}
Now originally in my project's build.gradle I have a publishSnapshot task followed by ordering logic using mustRunAfter method:
task publishSnapshot (dependsOn: ['createMyMediaArchive','publishMyMediaPublicationToSnapshotRepository'])
tasks.findByName("publishMyMediaPublicationToSnapshotRepository").mustRunAfter tasks.findByName("createMyMediaArchive")
publishSnapshot.mustRunAfter tasks.findByName("publishMyMediaPublicationToSnapshotRepository")
executing the publishSnapshot task gives below error:
Cannot invoke method mustRunAfter() on null object
tasks.findByName method doesn't seem to work here as it returns null.
Am I missing out on some basics?
EDIT 1 : END
EDIT 2 : START
The below build.gradle is an edited version of what I actually have. I am not allowed to share the script. But the script is identical in structure to what I have. The rest of build script is as it is as far as the structure and syntax is concerned, just the names changed. Gradle version is 3.5.1
build.gradle
import java.time.LocalDate;
import java.time.format.DateTimeFormatter
import java.text.SimpleDateFormat
import Tasks.PublishArtifacts
import org.gradle.api.GradleException
buildscript {
repositories {
abcRelease()
}
dependencies {
classpath "org.codehaus.groovy.modules.http-builder:http-builder:0.7"
classpath "commons-collections:commons-collections:3.2.1"
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:4.9.10"
}
}
repositories {
mavenCentral()
abcSnapshot()
xyzRelease()
}
apply plugin: 'maven-publish'
apply plugin: 'base'
apply plugin:'java'
apply from: "$rootDir/repositories.gradle"
def getMediaVersion(){
project.mediaVersion
}
configurations{
releaseMedia
}
publishing{
publications {
myMedia(MavenPublication) {
artifactId project.artifactId
artifact "$project.artifactId"+"-"+getMediaVersion()+".tgz"
version getMediaVersion()
}
}
repositories project.artifactoryRepositories
}
task publishSnapshot (dependsOn: ['createMyMediaArchive','publishMyMediaPublicationToSnapshotRepository'])
tasks.findByName("publishMyMediaPublicationToSnapshotRepository").mustRunAfter tasks.findByName("createMyMediaArchive")
publishSnapshot.mustRunAfter tasks.findByName("publishMyMediaPublicationToSnapshotRepository")
afterEvaluate { evaluated ->
evaluated.tasks.findByName("publishMyMediaPublicationToSnapshotRepository").configure {
println "My Media name --------- "+it.name
}
}
task printTaskName{
doLast{
println "task name found is :--- "+tasks.findByName("publishMyMediaPublicationToSnapshotRepository") // This returns task name as exected
}
}
task createMyMediaArchive{
doLast{
//code for creating media
}
}
EDIT 2 : END
EDIT 3: START
If I run the tasks individually, i.e. first running task createMyMediaArchive and then running task publishSnapshot ,where the taskpublishSnapshot depends on
task publishHelmMediaPublicationToSnapshotRepository, ie.
task publishSnapshot (dependsOn: ['publishHelmMediaPublicationToSnapshotRepository'])
then both the tasks run successfully. This proves that gradle does have the task publishHelmMediaPublicationToSnapshotRepository pre-configured.
Also gradlew tasks --all prints out this task.
This behavior is making things look more confusing to me.
EDIT 3 : END

A lot of the configuration performed by the maven-publish plugin is done lazily.
Wrapping in afterEvaluate should work.
afterEvaluate { evaluated ->
evaluated.tasks.findByName("publishMyMediaPublicationToSnapshotRepository").configure {
println it.name
}
}

Related

Error using dependsOn to call task from another gradle file

I am working with a build.gradle file that has multiple ways to specify executions for a task - setup. To call a task from another gradle file - runtests.gradle, I created a task - testTask and added task dependency using dependsOn, but this implementation does not seem to work and giving out an error like :
Could not find property 'testTask' on root project 'GradleFile
My build file looks like this :
build.gradle
task setup(dependsOn: testTask) <<
{
println "In main execution"
}
// new task
task testTask(type: GradleBuild) {
if (getEnvironmentVariable('RUN_TEST').equalsIgnoreCase("true")) {
buildFile = "../Behave/runtests.gradle"
tasks = ['mainTask']
}
else {
println "Exiting runTests Task"
}
}
setup.doFirst {
println "In first execution"
}
setup.doLast {
println "In last execution"
}
D:\>gradle -q GradleFile/build.gradle setup
I am not looking to make much changes to existing tasks, so is there any other workaround I should try?
I have been through many links but could not find anything that suits this scenario. Looking for suggestions please.
Gradle is sensitive to the ordering of tasks in the build script if a task instance is given in the dependsOn. The task setup depends on task (instance) testTask which, at the moment the build script is compiled, doesn't exist yet. The most common options to solve the issue are:
Define task setup below testTask:
task testTask(type: GradleBuild) {
}
task setup(dependsOn: testTask) {
}
Use a relative path to the task, i.e. the task's name, in the dependsOn
task setup(dependsOn: 'testTask') {
}
task testTask(type: GradleBuild) {
}
Please find more details in Javadoc of Task.

Execute gradle task on sub projects

I have a MultiModule gradle project that I am trying to configure.
Root
projA
projB
other
projC
projD
projE
...
What I want to be able to do is have a task in the root build.gradle which will execute the buildJar task in each of the projects in the other directory.
I know I can do
configure(subprojects.findAll {it.name != 'tropicalFish'}) {
task hello << { task -> println "$task.project.name"}
}
But this will also get projA and projB, I want to only run the task on c,d,e...
Please let me know the best way to achieve this.
Not entirely sure which of these you're after, but they should cover your bases.
1. Calling the tasks directly
You should just be able to call
gradle :other/projC:hello :other/projD:hello
I tested this with:
# Root/build.gradle
allprojects {
task hello << { task -> println "$task.project.name" }
}
and
# Root/settings.gradle
include 'projA'
include 'projB'
include 'other/projC'
include 'other/projD'
2. Only creating tasks in the sub projects
Or is it that you only want the task created on the other/* projects?
If the latter, then the following works:
# Root/build.gradle
allprojects {
if (project.name.startsWith("other/")) {
task hello << { task -> println "$task.project.name" }
}
}
and it can then be called with:
$ gradle hello
:other/projC:hello
other/projC
:other/projD:hello
other/projD
3. Creating a task that runs tasks in the subprojects only
This version matches my reading of your question meaning there's already a task on the subprojects (buildJar), and creating a task in root that will only call the subprojects other/*:buildJar
allprojects {
task buildJar << { task -> println "$task.project.name" }
if (project.name.startsWith("other/")) {
task runBuildJar(dependsOn: buildJar) {}
}
}
This creates a task "buildJar" on every project, and "runBuildJar" on the other/* projects only, so you can call:
$ gradle runBuildJar
:other/projC:buildJar
other/projC
:other/projC:runBuildJar
:other/projD:buildJar
other/projD
:other/projD:runBuildJar
Your question can be read many ways, hope this covers them all :)
All of the ways mentioned by Mark can be used but all of them have some cons. So I am adding one more option:
4. Switching the current project
gradle -p other hello
This switches the "current project" and then runs all tasks named hello under the current project.
Example 5. Defining common behavior of all projects and subprojects,
allprojects {
task hello {
doLast { task ->
println "I'm $task.project.name"
}
}
}
subprojects {
hello {
doLast {
println "- I depend on water"
}
}
}
From the Gradle documentation,
https://docs.gradle.org/current/userguide/multi_project_builds.html

Gradle dependency does not work as my expectation

I have two sub projects subproject1 and subproject2. I'd like to add some classes from subproject2 to subproject1 and get the subproject1.jar. Below is my gradle file:
task copyClasses (dependsOn: [ ':subproject1:clean', ':subproject1:classes']) {
println "copyClasses "
doLast {
Task study = tasks.getByPath(':subproject1:jar')
study.doFirst {
copy {
println "copy ... "
println sourceSets.main.output.classesDir
println project(':subproject1').sourceSets.main.output.classesDir
from sourceSets.main.output.classesDir
into project(':subproject1').sourceSets.main.output.classesDir
}
}
}
}
task jarUpdated (dependsOn: [ clean, classes, copyClasses, ':subproject1:jar']) {
doLast {
println "jarUpdated"
}
}
But I got the build sequence as below:
$ gradle jarUpdated
copyClasses
:subproject1:compileJava
:subproject1:processResources UP-TO-DATE
:subproject1:classes
:subproject1:jar
:subproject2:compileJava
:subproject2:processResources UP-TO-DATE
:subproject2:classes
:subproject2:clean
:subproject1:clean
:subproject2:copyClasses
Calling Task.doFirst(Closure) after task execution has started has been deprecated and is scheduled to be removed in Gradle 2.0. Check the configuration of task ':subproject1:jar'.
:subproject2:jarUpdated
jarUpdated
BUILD SUCCESSFUL
My expectation is:
$ gradle jarUpdated
:subproject2:clean
:subproject2:compileJava
:subproject2:processResources UP-TO-DATE
:subproject2:classes
:subproject1:clean
:subproject1:compileJava
:subproject1:processResources UP-TO-DATE
:subproject2:copyClasses
copyClasses
copy ...
:subproject1:jar
:subproject2:jarUpdated
jarUpdated
BUILD SUCCESSFUL
Would you please suggest or point out what I missed? Thanks a lot!
The "easiest" way to do exactly what you asked for is probably something like this in your subproject1 build file.
jar {
from tasks.getByPath(':subproject2:compileJava')
}
However this is a very simplistic approach with a LOT of caveats, for example
Subproject 1 can not compile against subproject 2 classes
Any dependencies of Subproject 2 will not be included
etc
I would actually advise declaring subproject2 as a dependency of subproject1 and using one of the plugins that Peter suggested.

Gradle war ignores transitive dependencies when using 'configurations.runtime.asPath' in custom task

I'm facing behavior that I can't explain, using gradle 1.10 I have:
settings.gradle:
include('lib1', 'lib2', 'web')
build.gradle:
subprojects {
apply plugin: 'java'
}
project(':web') {
apply plugin: 'war'
dependencies {
compile project(':lib1')
}
task myTask(type: JavaExec, dependsOn: 'compileJava') {
main = "some.thirdparty.Class"
args "--searchPath", configurations.runtime.asPath
}
}
project(':lib1') {
dependencies {
compile project(':lib2')
}
}
project(':lib2') {
}
When I run gradle clean war I only have lib1.jar in war/build/libs/web.war/WEB-INF/lib.
To make WEB-INF/lib contain both lib1.jar and lib2.jar I have to:
move project('web') block to the end of the file
update configurations.runtime.asPath to configurations.runtime (but I need to provide class path as a path, so it is not a solution)
I read the build lifecycle description, tried to compare --debug outputs but that didn't help.
Why is this happening? And what would be a good solution to provide the module runtime class path as a path in JavaExec task please?
asPath resolves the configuration, but resolution will only work correctly if it happens at execution time rather than configuration time (in particular in the presence of project dependencies). Try to wrap the args line with doFirst { ... }.

Grails gradle "a task with that name already exists"

I'm trying to create a test task rule using the example provided in the grails gradle doc but I keep getting "a task with that name already exists" error.
My build script is as follows:
import org.grails.gradle.plugin.tasks.* //Added import here else fails with "Could not find property GrailsTestTask"
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "org.grails:grails-gradle-plugin:2.0.0"
}
}
version "0.1"
group "example"
apply plugin: "grails"
repositories {
grails.central() //creates a maven repo for the Grails Central repository (Core libraries and plugins)
}
grails {
grailsVersion = '2.3.5'
groovyVersion = '2.1.9'
springLoadedVersion '1.1.3'
}
dependencies {
bootstrap "org.grails.plugins:tomcat:7.0.50" // No container is deployed by default, so add this
compile 'org.grails.plugins:resources:1.2' // Just an example of adding a Grails plugin
}
project.tasks.addRule('Pattern: grails-test-app-<phase>') { String taskName ->
println tasks //shows grails-test-app-xxxxx task. Why?
//if (taskName.startsWith('grails-test-app') && taskName != 'grails-test-app') {
// task(taskName, type: GrailsTestTask) {
// String testPhase = (taskName - 'grails-test-app').toLowerCase()
// phases = [testPhase]
// }
//}
}
Running $gradle grails-test-integration
or in fact anything of the form $gradle grails-test-app-xxxxxxxx yields the error "Cannot add task 'gradle grails-test-app-xxxxxxxx as a task with that name already exists".
Can someone please advise how I can resolve this error? Thanks.
If you don't mind overriding the task created by the plugin, you might want to try
task(taskName, type: GrailsTestTask, overwrite: true)
In general, when using task rules that can be called multiple times (for instance if you have multiple tasks depending on a task eventually added by your rules), I use the following test before actually creating the task:
if (tasks.findByPath(taskName) == null) {tasks.create(taskName)}
This will call the task() constructor only if this task name does not exists.

Resources