Gradle: setWorkingDir not working in 1.5.0

[pschyma]

Describe the bug
I'm setting the working directory in for quarkusDev task in my Gradle build file via

tasks {
  quarkusDev {
    setWorkingDir(projectDir.path)
  }
}

After updating to any 1.5.0 version of Quarkus I get ${proejct.path}\build\classes\java\main\. as working dir in the app.

Expected behavior
The working directory of the application is set properly.

Actual behavior
The setting is ignored and the classes path is used.

To Reproduce
Steps to reproduce the behavior:

1. Create a new project.
2. Set a working directory in task configuration (e.g. C:\tmp on Windows).
3. Access current working directory in Java (e.g. System.getProperty("user.dir") or Path.of("")).

Environment (please complete the following information):

• Output of uname -a or ver: Microsoft Windows [Version 10.0.18363.836]
• Output of java -version:

openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02)
OpenJDK 64-Bit Server VM GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02, mixed mode, sharing)

• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.5.0.Final and 1.5.0.CR1
• Build tool (ie. output of mvnw --version or gradlew --version): 6.4.1

Additional context
This does also not work on a Linux machine.

[glefloch]

@pschyma, I can reproduce the issue. It seems the task is ignoring the workingDir property in favour of the extension workingDir property.

quarkus/devtools/gradle/src/main/java/io/quarkus/gradle/tasks/QuarkusDev.java

Line 377 in 3dfb48f

action.commandLine(args).workingDir(extension().workingDir());

Setting the working directory in the quarkus extension as below works for me:

quarkus {
    workingDir="/tmp"
}

@aloubyansky, should we remove the property from the quarkusDev task and update the doc?

[aloubyansky]

@pschyma will the workaround mentioned by @glefloch work for you? Or you have reasons for a workingDir per command?
I remember having an issue with the workingDir. It was not properly resolved and the process wouldn't start.

[pschyma]

The workaround works for me, yes.

I'm curious about the reason for the current implementation. My idea was (is) that this property is used to "simulate" the directory in which a built runner whould have been started; and thus it has a tight relation to the quarkusDev task - like e.g. the args property.

[aloubyansky]

That's correct @pschyma. I started to see issues in our testsuite after I introduced more task dependencies and the parameters weren't properly resolved at the initialization stage. We should probably revisit this. @glefloch in case you are looking for the next Gradle issue to work on, perhaps this could be a candidate ;)

[glefloch]

@aloubyansky, I was actually looking for an issue to work on.
I will start to work on this and add test to make sure this introduce no regressions.

[aloubyansky]

Excellent. Thanks, @glefloch