From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

that returns a `ProjectDescriptor` - which only has APIs for `File`. And `settings` scripts do not have access to `ObjectFactory`

it's not mine, but I was told that `gradle.rootProject.layout` is the solution

ahh - `gradle.rootProject.layout` is different, so yes that works, assuming accessing `Gradle` is okay

```Could not create provider for value source Settings_gradle.BuildScanStartParametersValueSource.
&gt; The root project is not yet available for build.```
nope :disappointed:

I’m trying to get a `Provider&lt;FileContents&gt;` for the root `gradle.properties` within `settings.gradle.kts`. This requires a `RegularFile` as input

Actually why? Assuming a typical layout where the settings directory is in the same directory as the root project directory, you can simply access the Gradle properties. If you tell what you want to achieve, you might get better recommendations.

&gt; it's not mine, but I was told that `gradle.rootProject.layout` is the solution
&gt; 
That cannot work as the root project is not yet available when the settings script is evaluated. Hence the exception he got. You could only do it in a delayed action like with `gradle.rootProject { ... }` or similar.

It seems that you can get `ObjectFactory` in `settings.gradle.kts` in some way, if that helps (from <https://github.com/gradle/gradle/issues/14171|gradle#14171>):
```import org.gradle.kotlin.dsl.support.serviceOf
...
val objects = gradle.serviceOf&lt;ObjectFactory&gt;()```

Is `serviceOf` now considered public API <@U02DF9JDXJM>?
Cédric told me it is internal API even if not in an internal package only meant for implementation of version catalogs when I recommended it in build scripts.

Yeah good point, status of that hasn’t change yet. So I wouldn’t recommend it for some public plugin that has to support multiple Gradle versions.

I still find it very strange that it is in a public package but considered internal, maybe it should be moved as long as it is not considered public api. :wink:

Yeah, that is unfortunate. For Kotlin DSL we have a note about that in docs: <https://docs.gradle.org/nightly/userguide/kotlin_dsl.html#sec:implicit_imports>. But we should do that better, definitely.

Oh, I think I never have seen that note. And even if, I would have forgotten and probably just look for `.internal.` in the package name probably. :-(