Workaround is to use a Provider<Object> on the task side.

@gradle/configuration-cache Could you take a look at this one?

@gradle/bt-configuration-cache I encountered this earlier today and used the workaround from @melix (thank you!) which worked well. Now encountering something that looks the same, but for Extension objects:

Extension of type 'AwsDevCredentialsExtension' does not exist. Currently registered extension types: [..., AwsDevCredentialsExtension, ...]

Edit:
I think in in my case it could be because the extension is attempting to be acquired in an applied script i.e. apply(from = another-script.gradle.kts). The extension that gets created by the plugin is attached to a different class loader than the one that is used in the applied script, which is causing the issue here. It looks like this in the logs when I change to doing project.extensions.getByName("awsDevCredentials") as AwsDevCredentialsExtension.

class gebuild.aws.AwsDevCredentialsExtension cannot be cast to class gebuild.aws.AwsDevCredentialsExtension (gebuild.aws.AwsDevCredentialsExtension is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @30cb7b03; gebuild.aws.AwsDevCredentialsExtension is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @19c59d0e)

Edit 2:
Also affects NamedDomainObjectContainers.

Hi team! Do you plan to investigate this one? It is quite problematic as a "well designed" plugin can be facing this issue independently in a multi-project build, so testing wouldn't highlight the problem.

@melix if you add the plugin to the root build.gradle with apply: false does it workaround the issue?

i.e. in the build.gradle for the root project (parent of core and lib):

plugins {
    id 'my.plugin' apply false
}

There's not a single week where I'm not pinged about this bug. Can this be prioritized, please 🙏

Cannot set the value of task ':oci:collectReachabilityMetadata' property 'metadataService' of type org.graalvm.buildtools.gradle.internal.GraalVMReachabilityMetadataService using a provider of type org.graalvm.buildtools.gradle.internal.GraalVMReachabilityMetadataService.

As a workaround if you make your service return serializable objects you can use reflection combined with serializing/deserializing to get around class cast exceptions.

service = new MyServiceCrossClassLoaderDelegate(serviceProvider.get())

static class MyServiceCrossClassLoaderDelegate {
    private BuildService<?> delegate;
    
    public MyServiceCrossClassLoaderDelegate(BuildService<?> delegate) {
        this.delegate = delegate;
    }
    
    public MyUploadResponse upload(String repoKey, String itemPath, Object file, Map<String, Object> properties) {
        return castAcrossClassLoaders(delegate.class.getMethod("upload", String.class, String.class, Object.class, Map.class)
            .invoke(delegate, repoKey, itemPath, file, properties), MyUploadResponse.class);
    }
}

    /**
     * Converts a <i>Serializable</i> object from the class of one classloader to the same class of another classloader.
     * <p>
     * Classes using this should set the serialVersionUID and modify it when the definition changes to detect missmatches.
     * <p>
     * <b>Important</b>: Classes should be data classes. Do not attempt to serialize classes that reference Gradle or other 
     * external libraries or classloading nightmares may happen. Transient fields will be lost.
     * 
     * @param <T>
     * @param obj   the object from classloader A
     * @param clazz the class to cast to from classloader B
     * @return the cast object
     */
    public static <T extends Serializable> T castAcrossClassLoaders(Object obj, Class<T> clazz) {
        if (obj == null) {
            return null;
        }
        
        Class<?> objClazz = obj.getClass();
        
        if (objClazz == clazz) {
            // No need to cast the class was loaded by the same classloader
            
            return clazz.cast(obj);
        }
        
        if (objClazz.getName() != clazz.getName()) {
            throw new IllegalArgumentException("Unable to perform cross-classloader casting. Class '" + objClazz.getName() + "' is not the same as '" + clazz.getName() + "'");
        }
        
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        
        try (ObjectOutputStream it = new ObjectOutputStream(baos)) {
            it.writeObject(obj);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        
        
        Object result = null;
        try (ObjectInputStream it = new ObjectInputStream(new ByteArrayInputStream(baos.toByteArray()))) {
            result = it.readObject();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        
        return clazz.cast(result);
    }

I'm running into this issue as well, when writing a custom plugin that delegates to another one that has a BuildService.

This was very tricky to diagnose and identify, and we may wind up going with either a pattern of maintaining the same order for our plugins or requiring downstream consumers to supply the plugin, which defeats the purpose of mine.

For those of us who are consumers of plugins with Providers that have a reified type, how can we move forward? There's no guarantee that any of those tasks or values would be serializable so I can't move them between classloaders with any safety.

If sharing the service between subprojects is not mandatory and have an instance per project is acceptable, one can prefix the service name with the project name when registering:

class MyPlugin: Plugin<Project> {
    override fun apply(project: Project) {
        val downloadClientProvider = project.gradle.sharedServices.registerIfAbsent("${project.name}_${DownloadClient.SERVICE_NAME}", DownloadClient::class.java)
        project.tasks.register("download", Download::class.java) { task ->
            task.downloadClient.set(downloadClientProvider)
            task.usesService(downloadClientProvider)
        }
    }
}

@tamaracha the whole purpose of a "shared build service" is to share state between all projects in a build. What you've proposed is functionally just a project extension.

Actually, it would be nice to have something like this "shared build service" to share state within a single project. The docs aren't clear at all about how to do that. DSL extensions (if you mean them) are user-facing, and do not feel like the right place where to put implementation details.

Why shouldn't there be a general DI-usable custom service concept where the scope can be selected (build-wide singletons, project-wide singletons, instances)?

Actually, it would be nice to have something like this "shared build service" to share state within a single project. The docs aren't clear at all about how to do that. DSL extensions (if you mean them) are user-facing, and do not feel like the right place where to put implementation details.

A plugin is applied to a project, so instantiating the class via constructor is enough as it will not be shared between projects.

Anyway, that is out scope of this issue, as build services are created to share the state between multiple projects that are using your plugin.

Are there any thoughts about disabling/deprecating per-project classloaders (which seems to be the underlying issue here)?

Almost every project I come into has plugins loaded in the root build script with apply(false). Could that be the default recommendation moving forward? Not only will that fix the BuildService issue but it will also fix other classpath issues when different plugin use conflicting dependencies. And potentially even less work for the JVM (less classloaders).

Plugin implementers who need a separated classloader can always use workers or create their own ClassLoader.

It won't happen overnight but clear guidance would be welcome.

That sounds like the scope of this issue:

• Rework plugin classloader hierarchy #25616