gradle WriteProperties task does not create properties file unless the task is ran directly

I am trying to generate properties files in a non-Android Java project, but for some reason even though the task runs when I build the project with ./gradlew assembleDist or run it with ./gradlew foo:run, the properties file isn't created. The task is defined in a subproject and looks like this:

task writeProperties(type: WriteProperties) {
    outputFile 'src/main/resources/foo.properties'
    property 'version', version
    property 'releaseType', releaseType
    property 'date', date
    println("task ran")
}

task ran gets printed when I execute the other gradle tasks, indicating that the task ran, but no foo.properties file shows up in the specified path. Weirdly enough, if I run the writeProperties task directly with ./gradlew foo:writeProperties, the file gets created and populated with the correct variables.

I've tried wrapping the statements above with doFirst{} and doLast{} but I get errors like the following:

Cause: path may not be null or empty string. path='null'

Does anyone have any idea what I could be doing wrong? I've been banging my head against this for hours and am running out of ideas. Thanks!

update: I managed to solve it with information provided in the accepted answer. I had to add compileJava.finalizedBy(writeProperties) to get the task to actually run as part of the build tasks. As the top answer mentioned, println was essentially lying to me, as that was being printed during the configuration phase but the task action was not being ran.

The actual problem with your code is that your println statement is not telling the truth. The code in the task configuration closure runs when the task gets configured, not when it gets executed. So everytime you run another task from the command line, your task gets configured and the println writes to the command line, but the actual task action is not executed. You should pack your println into a doLast, so that it actually runs after the .properties file has been created.

task myTask {
    println 'task configured'
    doLast {
        println 'task executed' 
    } 
} 

If you want your task to run without specifying it on the command line, you need to setup task dependencies using dependsOn or finalizedBy.

The described issue is not a problem. What's happening is exactly how Gradle works. I too have struggled with understanding why this behavior is correct! I'm providing an answer to help bring some clarity as to what's going on. Algebo is not alone in trying to understand how Gradle works. Algebo did a great job in describing what he observed and hopefully my answer takes out some of the mystery of what's going on.

First thing to understand is that gradle evaluates the code in three passes: initialization, configuration and execution.

During initialization, gradle figures out which projects are to be included in the build.

During configuration, the tasks are created and configured and added to the build graph. When a task is configured, you need to tell gradle what are the inputs and outputs to the task. Gradle uses that information to know whether it actually needs to execute the task or not. (i.e. if the inputs and outputs of a task is up-to-date, then you can skip the execution of the task)

During execution, gradle then executes the actions associated with task.

With the above explanation, let's look at what's happening with Algebo's code. The first thing that Algebo notices is that he sees the "task ran" message. So why was that? That's because that code was executed during the gradle configuration phase. (Lukas answer does a good job explaining this same observation) So, all that's done at this time is that the "writeProperties" task object (which is of type "WriteProperties") get configured. And of course, Algrebo correctly notices that the "foo.properties" file was not created. And that of course is because the task was only configured and not yet execute.

The next thing Algebo tries is to put the code in the task block in a doFirst and a doLast block. When Algebo tries that, he gets the error message that the path may be null or empty. The doFirst and doLast the blocks of code that define a task action. As I stated earlier, it the task actions that get executed during the task execution pass. So why does Algebo get that error. In the case of the "WriteProperties" task, it requires that the "outputFile" to be configured. But, Algebo moved the outputFile statement to a task action block. In other words, the outputFile has not been defined at the time either the doFirst or doLast code gets executed. The "WriteProperties" task needs that define prior to the task actions being performed. So that explains that observed behavior.

So why does it work when he executes the task directly using ./gradlew foo:writeProperties directly. Well, that's because the task is properly configured, and when he executes it directly, it executes the task actions associated with the task. Well, Algebo didn't define any task actions, so there's none to be executed, and once the task actions have completed (none), the WriteProperies task concludes by writing of the defined properties to the outputFile. And that's of course what Algebo observed.

And lastly, Algebo noticed that he could get the task to do what he wanted to by adding the statement: compileJava.finalizedBy(writeProperties). In that case, the WiteProperties task has been configured. Additionally during the configuration pass, that task was added to the build graph. In other words, that task was configured to be run when the "compileJava" task completed. When the "writeProperties" task is executed, it has been properly configured, so it executes the task actions for the task (none in this case) and when done the "WriteProperties" task concludes by writing the properties to the "outputFile".

With all the above said, there's still another issue with the "writeProperties" task as defined. Gradle now wants user to define the inputs and outputs of all tasks. Gradle uses that imformation to determine whether a task needs to be executed or skipped if it already up-to-date. In Algebo's example, the inputs are: "version", "releaseType" and "date" and the outputs are the file "src/main/resources/foo.properties". (Note: gradle doesn't know that "outputFile" is part of "outputs"). The "writeProperties" task doesn't have its inputs and outputs configured. So "writeProperties" will always get executed even if nothing has changed since it was last executed. In Algebo final working solution, his properties file would not get rebuilt if for example "version" changed and the compileJava task was already up-to-date.

For additional information, I found this to be helpful.

1. generate new code in the build folder (not main source)

2. add the generated files to the source set

3. link new task to the build chain

   ext.genRes = 'build/generated_src/main/resources'
   sourceSets {
   main {
   resources {
   srcDir(genRes)
   }
   }
   }

   ext.genResFoo = genRes + 'foo.properties'
   ext.releaseType = 'test'

   task genResources(type: WriteProperties) {
   outputFile genResFoo
   property 'version', version
   property 'releaseType', releaseType
   property 'date', new java.util.Date()
   doLast {
   println("writeProperties ran ${genResFoo}")
   }
   }
   processResources.dependsOn genResources