Investigate how to make sure that the logic we use for determining the location of the gradle-daemon-jvm.properties is somehow accessible from here, or from a dedicated service.

Here are some changes based on the feedback provided:

• The ScriptFileResolvedListener, ScriptFileResolverListeners and BuildLayoutFactory providers got moved from to GlobalScopeServices.java to BasicGlobalScopeServices.java
  • This isn't exactly a must since we had before several usages of new BuildLayoutFactory(), however, simplifies a bit to be able to use BuildLayoutFactory on the launcher from service
• Storing BuildLayoutResult on Parameters this aligns with already existing class with same name on ProviderConnection.Parameters
  • This will make it easier potentially to merge those in the future but also keeps consistency between the both
• Passing to DaemonClientFactory the BuildLayoutConfiguration from stored BuildLayoutResult on Parameters
  • Avoid passing directly the BuildLayoutResult since contains unnecessary methods like applyTo(). In addition is easy to convert one into another by using already existing BuildLayoutResult.toLayoutConfiguration() method
  • Since both Parameters classes CLI and TAPI now stores the BuildLayoutResult obtaining it isn't a problem to pass it down to DaemonClientToolchainServices

@vmadalin Sorry for the long delay. I rebased this and will be validating it locally before doing one last review.

The following builds have failed:

• Ready for Nightly (Trigger) (Check)
  • Build Scan

@bot-gradle test RfN

The following builds have passed:

• Ready for Nightly (Trigger) (Check)
  • Build Scan