Tasks can be renamed. Is this an intended feature?


(Attila Kelemen) #1

Since ‘AbstractTask’ has a ‘setName’ method, the task can be renamed. This introduces some strange behaviour. See the following build file:

apply plugin: 'java'
  jar {
    name = 'myJar'
}
  println "This works: ${project.myJar}"
println "prints null: ${project.tasks.findByName('jar')}"
println "but this works: ${project.tasks.findByName('myJar')}"
  // println "This fails: ${project.jar}"

Executing the “gradle jar” works in some cases (with different build scripts) but in this case (at least, for me), “gradle myJar” will run the “:jar” task (notice that the path remains unchanged).

I have not trully verified it yet but I believe that renaming a task might corrupt some set containing task (finding it by name).

I have came across this in a project which (probably) accidentally set this property: ‘jar { manifest { name = “New Name” }}’. Should setting the name be prevented or is it an intended feature?


(Szczepan Faber) #2

Currently, there’s no public api to rename a task. AbstractTask is private (unfortunately it leaks do to the class hierarchy) and not listed in the public docs. Once we rework the task hierarchy and sprinkle it with some metaprogramming it should be possible to avoid dragging the methods from the private parent classes. Or at least control it better and fail when users excess the private api.

For now, please do not rename tasks :slight_smile:

Hope that helps!