Project accessors enabled, but root project name not explici

Error message

Project accessors enabled, but root project name not explicitly set for '{}'. Checking out the project in different folders will impact the generated code and implicitly the buildscript classpath, breaking caching.

What it means

Emitted from DefaultDependenciesAccessors.writeProjectAccessors -> warnIfRootProjectNameNotSetExplicitly when type-safe accessors are generated but the root project's name is only the default (directory-derived) one (ProjectDescriptorInternal.isExplicitName() == false). The generated accessor code embeds the root project name, so the buildscript classpath hash changes when the same build is checked out under a different folder name, breaking build caching and configuration cache reuse across checkouts.

Source

Thrown at platforms/software/dependency-management/src/main/java/org/gradle/api/internal/catalog/DefaultDependenciesAccessors.java:185

            throw new RuntimeException(e);
        }
    }

    private void writeDependenciesAccessors(DefaultVersionCatalog model) {
        executeWork(new DependencyAccessorUnitOfWork(model));
    }

    private void writeProjectAccessors(ProjectDescriptorRegistry projectRegistry) {
        if (!assertCanGenerateAccessors(projectRegistry)) {
            return;
        }
        warnIfRootProjectNameNotSetExplicitly(projectRegistry.getRootProject());
        executeWork(new ProjectAccessorUnitOfWork(projectRegistry));
    }

    private static void warnIfRootProjectNameNotSetExplicitly(@Nullable ProjectDescriptorInternal project) {
        if (!project.isExplicitName()) {
            LOGGER.warn("Project accessors enabled, but root project name not explicitly set for '" + project.getName() +
                "'. Checking out the project in different folders will impact the generated code and implicitly the buildscript classpath, breaking caching.");
        }
    }

    private void executeWork(UnitOfWork work) {
        ExecutionEngine.Result result = engine.createRequest(work).execute();
        GeneratedAccessors accessors = result.getOutputAs(GeneratedAccessors.class).get();
        ClassPath generatedClasses = DefaultClassPath.of(accessors.classesDir);
        sources = sources.plus(DefaultClassPath.of(accessors.sourcesDir));
        classes = classes.plus(generatedClasses);
        classLoaderScope.export(generatedClasses);
    }

    private static boolean assertCanGenerateAccessors(ProjectDescriptorRegistry projectRegistry) {
        List<String> errors = new ArrayList<>();
        projectRegistry.getAllProjects()
            .stream()
            .map(ProjectDescriptor::getName)

View on GitHub (pinned to 534f27719b)

Solutions

Set the root project name explicitly in settings.gradle(.kts): rootProject.name = 'my-project'.
Pick a name that does not depend on the checkout directory and commit it with the settings file.
Verify the warning disappears on the next configuration and that build cache keys are now stable across checkouts.

Example fix

// before: settings.gradle.kts contains no root project name
// after:
rootProject.name = "my-app"

Defensive patterns

Strategy: validation

Validate before calling

# fail fast in CI if the root project name is not pinned
grep -n 'rootProject.name' settings.gradle settings.gradle.kts 2>/dev/null \
  || { echo 'MISSING rootProject.name — accessor generation will break caching'; exit 1; }

Prevention

Always set rootProject.name when creating a new build; treat it as required boilerplate like the settings file itself.
Never rely on the checkout directory name as project identity in CI pipelines or generated workspaces.
Add the grep check above to CI so renames or new modules cannot silently drop the setting.

When it happens

Trigger: A settings.gradle(.kts) that never sets rootProject.name = '...' while project accessors are generated (any build referencing projects.<name> or using version catalogs/accessors where generation is enabled). assertCanGenerateAccessors must pass first, then the isExplicitName check fails.

Common situations: CI checkouts into varying directories (Jenkins workspace-123, pipeline hashes); generated/Multi-repo setups; builds migrated from Ant/Maven where the folder was always the project name; accessing projects.foo in build scripts for the first time.

Related errors

AI-assisted analysis of gradle/gradle@534f27719b (2026-08-22). Data as JSON: /api/errors/35e6ded9de6fd7bb. Report an issue: GitHub.