Import properties from build.gradle and remove hardcoded quarkus.package.output-directory

[jacobdotcosta]

• Import properties defined in the build.gradle file using the syntax described below
• Replace the hard-coded output location if a quarkus.package.output-directory value is passed through configuration

build.gradle quarkus property definition:

quarkus {
    properties {
        set("package.type", "uber-jar")
        set("package.output-directory", "build-gradle-output-dir")
    }
}

Closes #28897
Closes #28896

[geoand]

Thanks a lot for this @jacobdotcosta!

I'll let @glefloch and @aloubyansky comment

[jacobdotcosta]

I'm not sure how to fix these errors as I'm not sure how they relate to this PR, could someone give me a hand?

Gradle Tests - JDK 11 Windows has 1 error which is the following:

2022-12-20T15:01:02.2716136Z 2022-12-20 15:01:01,864 SEVERE [org.jun.jup.eng.exe.JupiterEngineExecutionContext] (main) Caught exception while closing extension context: org.junit.jupiter.engine.descriptor.MethodExtensionContext@55877274: java.io.IOException: Failed to delete temp directory D:\a\quarkus\quarkus\integration-tests\gradle\target\junit10212038324867675530. The following paths could not be deleted (see suppressed exceptions for details): , src, src\main, src\main\resources

JVM Tests - JDK 17 MacOS M1 seems to fail to start the tests with:

2022-12-20T15:12:01.6643110Z Starting machine "podman-machine-default"
2022-12-20T15:12:02.2066100Z Waiting for VM ...
2022-12-20T15:12:17.2901010Z Mounting volume... /Volumes/actions-files/githubactions:/Volumes/actions-files/githubactions
2022-12-20T15:12:17.5569370Z Error: exit status 255
2022-12-20T15:12:17.5585510Z ##[error]Process completed with exit code 125.
...
2022-12-20T15:12:17.6112590Z /Volumes/actions-files/githubactions/actions-runner/_work/_temp/1f2eaa41-292c-4c25-99ae-db2308b6f743.sh: line 1: devtools/gradle/gradlew: No such file or directory
2022-12-20T15:12:17.6116990Z ##[error]Process completed with exit code 1.

[aloubyansky]

The MacOS is known to be problematic. The QuarkusPluginFunctionalTest.canDetectUpToDateBuild does seem to be related in some way though.

[jacobdotcosta]

I've downloaded the logs and checked the error messages. From what I can understand the io.quarkus.gradle.QuarkusPluginFunctionalTest#canDetectUpToDateBuild test case consists in executing the tests 2 times to make sure Gradle detects they haven't changed so it won't execute the tests again.

The problem seems to be that somewhere in the process the extension is trying to cleanup the src\main\resources sub-folder of the temporary project directory and that is failing probably because windows is locking a file. I cannot identify in the logs the step on which this failure is happening as the test class doesn't show up in the stacktrace.

@aloubyansky , could you assist me on a way of tracking this error? Do you know of any way I could try reproducing this error without having a MS Windows VM?

Thank you.

[aloubyansky]

Perhaps, instead @TempDir File projectRoot creating and recursively deleting a project dir "manually" will help?

[jacobdotcosta]

Perhaps, instead @TempDir File projectRoot creating and recursively deleting a project dir "manually" will help?

I think I found the problem. I wasn't closing the Stream that reads the application.properties file. This last commit should have fixed this.

[aloubyansky]

Thanks @jacobdotcosta!

[britter]

This should use lazy configuration APIs. So quarkusBuildProperties should not be of type Map<String, String> but MapProperty<String, String>. At the same time there should be an overload for set where value can be passed as a Property<String>.

Another issue with this solution is that is assumes everything is a string, but that's not the case. For example the package.output-directoy should probably be of type DirectoryProperty (see https://docs.gradle.org/current/userguide/lazy_configuration.html#working_with_files_in_lazy_properties).

[aloubyansky]

@britter thanks a lot for the review. Let us know if you would like to submit a PR yourself. That'd be much appreciated.

[jacobdotcosta]

Thank you for the feedback @britter , I'm reviewing the docs. I can also submit a PR to fix this, if you won't.

[britter]

I don't see myself doing this before the end of the month. So if you have some time @jacobdotcosta please go ahead.

[aloubyansky]

It doesn't look like it was fixed yet. @britter in case you have some time to contribute the fixes you mentioned previously, it'll be much appreciated. Thanks!

[britter]

@aloubyansky I managed to address the first part of it in #30713. I'm not sure it's possible to address the second part using a map based approached.