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

Gradle Community

&gt; ```of type xxx.ManifestService using a provider of type xxx.ManifestService.```
As there is two times the same FQCN, I'd say this is a class loader problem.
Your `ConfigureManifestTask` is coming from a different class loader than your `ManifestService` class and thus it cannot assign it as Java sees the `ManifestService` class the variable has as different from the `ManifestService` instance you give it.

Just set a breakpoint and compare the class loaders and you will most probably see that this is the case.

If you for example have root project `R` and sub-projects `A` and `B`, then apply plugin `X` containing `ManifestService` and `ConfigureManifestTask` to `A` and `B`, then the classes are on different class loaders and thus incompatible.
If then `A` is evaluated it registers the service with its class. Then `B` is evaluated and gets the service `A` has registered which is incompatible with it's own `ConfigureManifestTask`.

The solution would be to somehow add `X` to the class path of `R` as it would then be in a class loader that is the parent of both of the other class loaders and would fix the problem.

I have just tried following scenario: applied plugin `X` to `:R:A` and `:R:B` and run `jar` task from within the `R`. `configureManifest` task run as expected and altered manifests within `:R:A` and `:R:B`. So no problem with different class loaders here. Then I applied spring boot gradle plugin (without any configuration applied) to `:R:B` and tried to run `jar` the same way I did before and bum, the exception is back.

I will try to add `X` to `:R` without applying it..

This fix the issue!!! You saved my day, again. Thank you!
So there must be something wrong with the Spring Boot Gradle plugin - It somehow corupts the classloaders. Will create an issue on their github page.

Actually I wonder it worked without it. :smile: