Declaring explicitly the build service in the QuarkusBuildTask

[cdsap]

#44367 describes the issue of the task quarkusAppPartsBuild in a project applying quarkus in multiple modules.
The issue is reproducible in any project with the following configuration:

//module a
plugins {
    `java-library`
    id("io.quarkus")
    id("com.github.ben-manes.versions") version "0.51.0"
}

//module b
plugins {
    `java-library`
    id("io.quarkus")
    id("com.github.ben-manes.versions") version "0.51.0"
}

The property failing is additionalForcedProperties, which represents a BuildSerivice with the forced properties used by different tasks. The build service uses the @ServiceReference annotation that eliminates the need to declare the association between the task and the service explicitly. This is the part that is failing and I need to confirm with the Build Tool team If it's an expected behavior.
This PR implements the explicit declaration between the task and the service:

        task.getAdditionalForcedProperties().set(serviceProvider);
        task.usesService(serviceProvider)

https://docs.gradle.org/current/userguide/build_services.html#sec:service_references

• Fixes: Gradle 3.16 fails with missing required property additionalForcedProperties #44367

[geoand]

cc @aloubyansky

[cdsap]

I'm still working on a reproducer (without the QuarkusPlugin) for the Build Tool team, a simple:

public abstract class FooAbstractTask extends DefaultTask {
    @ServiceReference("forcedPropertiesService")
    abstract Property<ForcedPropertieBuildService> getAdditionalForcedProperties();

with the same configuration as the reproducer is not triggering the issue.

[cdsap]

Hi @aloubyansky, after discussing this issue with the Build tool team I'm opening for review this PR.
The original issue is described here gradle/gradle#17559

When registering a build service, due to how classloaders are shared or not among projects (essentially, projects with the same set of plugins applied share a classloader, though project hierarchies add additional variations), the class backing a shared build service registered by a plugin against a project may be incompatible with the class available under some other project.

The original idea was to remove the BuildService, but first, we need to address the issue where the actions nativeArgs and manifest need to be extracted from QuarkusBuild and included in the Quarkus extension to later be wired as inputs (I will create an issue soon). This PR addresses the issue by declaring a build service for each project where the Quarkus plugin is applied and explicitly declaring the build service in the task.

[aloubyansky]

Thanks a lot @cdsap for all the details and the patch

[aloubyansky]

The CI seems to be stuck again

[geoand]

Yeah, really weird. I would just rebase and force push if I were you @aloubyansky

[geoand]

👍🏽

Seems to be good now

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit b6324cd.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.