Why isn't the plugin being loaded in my build.gradle?

vonSpotz · March 7, 2022, 1:50pm

Hello,
I want to load especially the plugin Dependency Management Plugin

here is the code of my build.gradle

// build.gradle

buildscript {
    repositories {
        /* maven {
            url "https://plugins.gradle.org/m2/"
        }*/
        mavenCentral()
    }
    dependencies {
        classpath "io.spring.gradle:dependency-management-plugin:1.0.11.RELEASE"
    }
}



plugins {
    id 'java'
    id 'io.spring.dependency-management'
}

ext {
    set('springCloudVersion', "Hoxton.SR4")
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}

allprojects {

    repositories {
        mavenCentral()
    }

    dependencies {
      // ...
    }

}

group = 'com.microservicetest'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

Too bad it seems it doesn’t download the plugin and I get following error message

uild file '/home/max/IdeaProjects/Restaurant Rating App/build.gradle' line: 17

Plugin [id: 'org.springframework.boot'] was not found in any of the following sources:

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'org.springframework.boot'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:222)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.lambda$resolvePluginRequests$4(DefaultPluginRequestApplicator.java:148)
	at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:207)
	at org.gradle.util.internal.CollectionUtils.collect(CollectionUtils.java:201)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolvePluginRequests(DefaultPluginRequestApplicator.java:146)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.applyPlugins(DefaultPluginRequestApplicator.java:86)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:117)
	at org.gradle.configuration.BuildOperationScriptPlugin$1.run(BuildOperationScriptPlugin.java:65)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:74)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:74)
	at org.gradle.configuration.BuildOperationScriptPlugin.lambda$apply$0(BuildOperationScriptPlugin.java:62)
	at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.apply(DefaultUserCodeApplicationContext.java:44)
	at org.gradle.configuration.BuildOperationScriptPlugin.apply(BuildOperationScriptPlugin.java:62)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.lambda$applyToMutableState$0(DefaultProjectStateRegistry.java:325)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.fromMutableState(DefaultProjectStateRegistry.java:352)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.applyToMutableState(DefaultProjectStateRegistry.java:324)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:42)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:26)
	at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:35)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject.lambda$run$0(LifecycleProjectEvaluator.java:100)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.lambda$applyToMutableState$0(DefaultProjectStateRegistry.java:325)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.lambda$withProjectLock$3(DefaultProjectStateRegistry.java:385)
	at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:211)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withProjectLock(DefaultProjectStateRegistry.java:385)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.fromMutableState(DefaultProjectStateRegistry.java:366)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.applyToMutableState(DefaultProjectStateRegistry.java:324)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject.run(LifecycleProjectEvaluator.java:91)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:74)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:74)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:63)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:750)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:150)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.ensureConfigured(DefaultProjectStateRegistry.java:298)
	at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:41)
	at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:55)
	at org.gradle.configuration.DefaultProjectsPreparer.prepareProjects(DefaultProjectsPreparer.java:50)
	at org.gradle.configuration.BuildTreePreparingProjectsPreparer.prepareProjects(BuildTreePreparingProjectsPreparer.java:64)
	at org.gradle.configuration.BuildOperationFiringProjectsPreparer$ConfigureBuild.run(BuildOperationFiringProjectsPreparer.java:52)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:74)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:74)
	at org.gradle.configuration.BuildOperationFiringProjectsPreparer.prepareProjects(BuildOperationFiringProjectsPreparer.java:40)
	at org.gradle.initialization.VintageBuildModelController.prepareProjects(VintageBuildModelController.java:97)
	at org.gradle.initialization.VintageBuildModelController.doBuildStages(VintageBuildModelController.java:77)
	at org.gradle.initialization.VintageBuildModelController.prepareToScheduleTasks(VintageBuildModelController.java:64)
	at org.gradle.internal.build.DefaultBuildLifecycleController.lambda$prepareToScheduleTasks$0(DefaultBuildLifecycleController.java:104)
	at org.gradle.internal.build.DefaultBuildLifecycleController.lambda$withModelOrThrow$5(DefaultBuildLifecycleController.java:142)
	at org.gradle.internal.build.DefaultBuildLifecycleController.withModel(DefaultBuildLifecycleController.java:157)
	at org.gradle.internal.build.DefaultBuildLifecycleController.withModelOrThrow(DefaultBuildLifecycleController.java:140)
	at org.gradle.internal.build.DefaultBuildLifecycleController.prepareToScheduleTasks(DefaultBuildLifecycleController.java:102)
	at org.gradle.internal.buildtree.DefaultBuildTreeWorkPreparer.scheduleRequestedTasks(DefaultBuildTreeWorkPreparer.java:33)
	at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.lambda$doScheduleAndRunTasks$1(DefaultBuildTreeLifecycleController.java:83)
	at org.gradle.composite.internal.DefaultIncludedBuildTaskGraph.withNewTaskGraph(DefaultIncludedBuildTaskGraph.java:94)
	at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.doScheduleAndRunTasks(DefaultBuildTreeLifecycleController.java:82)
	at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.runBuild(DefaultBuildTreeLifecycleController.java:104)
	at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.scheduleAndRunTasks(DefaultBuildTreeLifecycleController.java:64)
	at org.gradle.tooling.internal.provider.runner.BuildModelActionRunner.run(BuildModelActionRunner.java:64)
	at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
	at org.gradle.internal.buildtree.ProblemReportingBuildActionRunner.run(ProblemReportingBuildActionRunner.java:47)
	at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:69)
	at org.gradle.tooling.internal.provider.FileSystemWatchingBuildActionRunner.run(FileSystemWatchingBuildActionRunner.java:91)
	at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:41)
	at org.gradle.launcher.exec.RootBuildLifecycleBuildActionExecutor.lambda$execute$0(RootBuildLifecycleBuildActionExecutor.java:40)
	at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:154)
	at org.gradle.launcher.exec.RootBuildLifecycleBuildActionExecutor.execute(RootBuildLifecycleBuildActionExecutor.java:40)
	at org.gradle.internal.buildtree.DefaultBuildTreeContext.execute(DefaultBuildTreeContext.java:40)
	at org.gradle.launcher.exec.BuildTreeLifecycleBuildActionExecutor.lambda$execute$0(BuildTreeLifecycleBuildActionExecutor.java:56)
	at org.gradle.internal.buildtree.BuildTreeState.run(BuildTreeState.java:53)
	at org.gradle.launcher.exec.BuildTreeLifecycleBuildActionExecutor.execute(BuildTreeLifecycleBuildActionExecutor.java:56)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor$3.call(RunAsBuildOperationBuildActionExecutor.java:61)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor$3.call(RunAsBuildOperationBuildActionExecutor.java:57)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor.execute(RunAsBuildOperationBuildActionExecutor.java:57)
	at org.gradle.launcher.exec.RunAsWorkerThreadBuildActionExecutor.lambda$execute$0(RunAsWorkerThreadBuildActionExecutor.java:38)
	at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:211)
	at org.gradle.launcher.exec.RunAsWorkerThreadBuildActionExecutor.execute(RunAsWorkerThreadBuildActionExecutor.java:38)
	at org.gradle.tooling.internal.provider.ContinuousBuildActionExecutor.execute(ContinuousBuildActionExecutor.java:103)
	at org.gradle.tooling.internal.provider.SubscribableBuildActionExecutor.execute(SubscribableBuildActionExecutor.java:64)
	at org.gradle.internal.session.DefaultBuildSessionContext.execute(DefaultBuildSessionContext.java:46)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.lambda$execute$0(BuildSessionLifecycleBuildActionExecuter.java:56)
	at org.gradle.internal.session.BuildSessionState.run(BuildSessionState.java:69)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:55)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:37)
	at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
	at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:63)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:31)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:58)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:42)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:47)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:31)
	at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:65)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
	at org.gradle.util.internal.Swapper.swap(Swapper.java:38)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:84)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
	at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)

Thanks !

jjustinic · March 8, 2022, 3:00pm

In this link you’ve provided, there’s examples of applying the plugin using two different methods. Your code uses part of one and part of the other. You need to choose which one you’re going to use and use it fully. You can’t pick parts of one and parts of the other.

vonSpotz · March 8, 2022, 3:24pm

Hello,
thanks for your answer.

I changed my build.gradle to

buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }

    }
    dependencies {
        classpath "org.springframework.boot:spring-boot-gradle-plugin:2.6.3"
        classpath "io.spring.gradle:dependency-management-plugin:1.0.11.RELEASE"
    }
}

plugins {
    id 'java'
}

apply plugin: "io.spring.dependency-management"
apply plugin: "org.springframework.boot"

ext {
    set('springCloudVersion', "Hoxton.SR4")
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}

allprojects {

    repositories {
        mavenCentral()
    }

    dependencies {
        implementation 'org.springframework.boot:spring-boot-starter-web'
        implementation 'org.springframework.cloud:spring-cloud-config-server'
        implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
        developmentOnly 'org.springframework.boot:spring-boot-devtools'
        testImplementation 'org.springframework.boot:spring-boot-starter-test'
    }

}

group = 'com.microservicetest'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

But it still doesn’t seem to load the plugins.

When I place my mouse over the spring dependencyManagement property (which is colored grey) a tooltip says:

No candidates found for method call dependencyManagement.

Also in the debug window

Build file '/home/max/IdeaProjects/Restaurant Rating App/build.gradle' line: 38

A problem occurred evaluating root project 'Restaurant Rating App'.
> Could not find method implementation() for arguments [org.springframework.boot:spring-boot-starter-web] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

When I delete the allprojects{} block I get the error message

Execution failed for task ':dependencies'.
> Could not resolve all dependencies for configuration ':detachedConfiguration1'.
   > Cannot resolve external dependency org.springframework.boot:spring-boot-dependencies:2.6.3 because no repositories are defined.
     Required by:
         project :
   > Cannot resolve external dependency org.springframework.cloud:spring-cloud-dependencies:Hoxton.SR4 because no repositories are defined.
     Required by:
         project :

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html

Thank you!

jjustinic · March 8, 2022, 4:41pm

It’s unclear what you’re trying to do here.

The more complete build.gradle file in your latest post has some plugins applied in the root project, but using allprojects for your Spring dependencies suggests that your Spring app is actually in a subproject.

You’re going to need to apply all the plugins and configuration that you need to the same project as the errors are based on plugins or configuration not being in the same project.

If you need more help identifying what this means, I would recommend that you provide a Short, Self Contained, Correct Example to avoid any ambiguities in what you may be working with.

vonSpotz · March 8, 2022, 5:24pm

Dear James,
this is the first build.gradle I have written. What I wanted to achieve was that the plugins and configurations/dependencies are not only available in the root project but also in the subprojects.

But the first goal to achieve of course is to get gradle to load the plugins in the root project.

Thank you very much!
Maximilian

PS: And I must rectify the omission of not telling that I am using IntelliJ IDEA as IDE.

Vampire · March 9, 2022, 12:01am

Actually my recommendation would be to not use the Spring dependency management plugin at all if you only use it to import the BOM.
For that I would recommend using the Gradle built-in BOM support instead.
The Spring dependency management plugin has some other features like porting over imho broken behavior from Maven world for people that prefer it.
But just for the BOM support, you don’t need the dependency management plugin.

Besides that, using buildscript with apply is legacy way.
The recommended way to apply plugins is to use the plugins { ... } block.

Another personal recommendation, especially if you are new to Gradle, use the Kotlin DSL.
For a small time-loss on initial building which is still slower with the Kotlin DSL, you get type-safety and amazing IDE support when using IntelliJ, opposed to when using Groovy DSL with its duck-typing.

You should also consider getting used to convention plugins right away instead of using allprojects { ... } or subprojects { ... } as these kind of cross-configurations are non-idiomatic nowadays and introduce coupling between projects which works against some performance features that are present or upcoming.

And for defining versions I’d recommend using the version catalog feature where you can centrally declare the version for the build in one place and then use it in your build scripts. Using ext is almost always a work-around you should avoid and feel dirty if you do. In the shown case a simple local variable with def springCloudVersion = 'Hoxton.SR4' would be more appropriate.

And finally, you might consider using the Java Toolchains feature instead of defining the sourceCompatibility, because then your build is independent of the Java version used to execute Gradle, so your Java 11 project can be built without problems even if Java 8 is used to execute Gradle.

Regarding the actual errors and warnings you get, the “No candidates found for method call dependencyManagement.” is just because of what I said about Groovy DSL vs. Kotlin DSL. Groovy is duck-typed and highly dynamic, the IDE cannot know what is actually available at runtime and what is not. With Kotlin DSL this problem does not exist. But then you also must use the plugins { ... } DSL to apply the plugins to get accessors generated for the applied plugins. The dependencyManagement block in your build script actually works as expected, besides that I wouldn’t use the whole plugin as mentioned above.

The “Could not find method implementation()” is because the java plugin that adds the implementation configuration is only applied to the root project, not the subprojects, but you try to declare dependencies for the subprojects. But as mentioned above, you should probably better use convention plugins instead of allprojects { ... } anyway.

The error you get after simply removing the allprojects block is pretty self-explanatory. You still try to download dependencies, but there are no repositories declared anymore which were defined in the allprojects block. Actually for repositories I would not put those in a convention plugin but define them in the settings script in a dependencyResolutionManagement block, then it simply works for all projects in the build consistently.

vonSpotz · March 9, 2022, 10:33am

Hallo Björn,

thank you very much for your response!

I want to add the sources of the plugins to the classpath for the root project and for all subprojects.

And this is, what the documentation says about the buildscript block

I know that apply is deprecated which was the reason I didn’t use it in the original post’s code of the build.gradle

Also I want to “apply” the dependencies from the sources a) to the parent project and b) to the subprojects

I thought for a) I need the plugins{} property and for b) I need that allprojects{} property.

But …

You say I shouldn’t use the buildscript {} to begin with.

I know one can append an apply false to the id function in a plugins{} block, such that it is resolved for the parent project and all the subprojects, but is only applied in subprojects via another use of plugins{} with id without version number in each one of them. (source: Using Gradle Plugins)

The reverse conclusion is that one wouldn’t need buildscript{} and call classpath with GNV of the plugin to resolve it for subprojects?

What are convention plugins please?

ahh yiss, want to feel dirrrty

Could I use the plugins {} block in the allprojects{} or subprojects{} block?

But ok, what are conventional plugins?

Danke

Vampire · March 9, 2022, 2:38pm

For multi-project builds, the dependencies declared with a project’s buildscript() method are available to the build scripts of all its sub-projects.

source:Build Script Basics

Yes, but it is totally irrelevant in your case.
If you apply a plugin using the plugins { ... } DSL, its classes are also available in the build script.
So wherever you apply a plugin using the plugins DSL the classes are available and the Gradle plugin portal which you declare as repository is the default repository to look up plugins anyway.

That quoted line is fully correct, but fully irrelevant in your case.

I know one can append an apply false to the id function in a plugins{} block, such that it is resolved for the parent project and all the subprojects, but is only applied in subprojects via another use of plugins{} with id without version number in each one of them. (source: Using Gradle Plugins)

I’d repeat my recommendation to use the version catalogs feature, then you can define the version of the plugin in the version catalog and just do plugins { alias(libs.plugins.springBoot) } or similar where you want it applied.

Or if you don’t want to use the version catalogs feature, then you can define the version of the plugin you want in the settings script in pluginManagement { plugin { ... } } and apply it anywhere you want it without specifying a further version too.

I know one can append an apply false to the id function in a plugins{} block

You can do that, but you shouldn’t.
This for the case where you want to not apply the plugin to the root project, but add it to the build script classpath to then use the legacy apply method for example in a subprojects or allprojects block to apply it the legacy way.

You could indeed also do it in the root build script and then apply in the subprojects build scripts without version, but as I said, for that I’d simply define the default version in the settings script unless you run into classloading problems that require the plugin to be available in the root project build script class path.

The reverse conclusion is that one wouldn’t need buildscript{} and call classpath with GNV of the plugin to resolve it for subprojects?

You basically never need the buildscript block, except for more or less one case.
If you want to use some library (not plugin) in your build script to implement some logic.
But then it is usually better to put that logic into a custom task or custom plugin anyway and thus removes the need for the buildscript block again.

Could I use the plugins {} block in the allprojects{} or subprojects{} block?

No, you would need to use the legacy way also for the java plugin if you insist on following that legacy cross-configuration approach.

What are convention plugins please?

Convention plugins are plugins where you implement your conventions.
For example the convention “I want the java plugin applied and these 10 dependencies declared as implementation dependencies”.
Convention plugins are often implemented using a precompiled script plugin that looks almost identical to a normal build script, but produces a proper plugin.
This plugin you then apply to the projects where you want these conventions directly in their build script, not using any allprojects or subprojects blocks.
Convention plugins are either put to buildSrc or - what I prefer - to an included build like gradle/build-logic/.
https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#header

vonSpotz · March 13, 2022, 7:00am

Hello Vampire,

Im sorry. I find the whole thing a bit confusing already ^^

I would like to ask three questions

First:
What I want to do is to load a (an external, especially in this case) plugin and add the source to the classpath to make the plugin resolvable for the root project. and beyond that I would like to make it resolvable for the sub projects.

Is there any reason to object against what I want to do?

Appending an “apply false” to the id functions options in a plugins{} block only makes the plugin resolvable and applicable in the subprojects, but not the root project. What is the reason for that?

Second:
You say you favor either a dependencyManagement block or - in the latest post - convention plugins. Sadly, the example which is linked to on the “Sharing dependency versions between projects” page of the userguide shows what a convention plugin looks like, but it doesn’t show how it is included into a build. Also, is it correct, that it doesn’t have much to do with writing normal custom plugins, where you implement Plugin<Project> first. In the example it is only a dependencies{} block. I conject “convention plugin” means a normal build script?

Because you mention buildSrc: Then again there are blogposts that obviously discourage using buildSrc recommend to use a component build

Third:

So to resolve plugins you would use a convention plugin and for dependencies you would use a settings script in a dependencyResolutionManagement{} block?

Thanks

Vampire · March 13, 2022, 2:50pm

What I want to do is to load a (an external, especially in this case) plugin and add the source to the classpath to make the plugin resolvable for the root project. and beyond that I would like to make it resolvable for the sub projects.

Is there any reason to object against what I want to do?

Besides that it is totally unnecessary and unidiomatic?
If you apply a plugin using the plugins block, it does not need to be part of the classpath, it is automatically added to it. You only need to add it to the root project classpath even if not applying it there but only in subprojects if you have classloader related problems.

Appending an “apply false” to the id functions options in a plugins{} block only makes the plugin resolvable and applicable in the subprojects, but not the root project. What is the reason for that?

That’s not correct. With apply false it is added to the respective project classpath but not applied and as the root project class loader is the parent of its subproject class loaders it is thus automatically also available in the sub projects classpaths. You just don’t need to do this usually except if you have classloader related problems as said before.

You say you favor either a dependencyManagement block or - in the latest post - convention plugins. Sadly, the example which is linked to on the “Sharing dependency versions between projects” page of the userguide shows what a convention plugin looks like, but it doesn’t show how it is included into a build. Also, is it correct, that it doesn’t have much to do with writing normal custom plugins, where you implement Plugin<Project> first. In the example it is only a dependencies{} block. I conject “convention plugin” means a normal build script?

You mix up two different things.

A convention plugin is semantic. It means a plugin (no matter how it is implemented) that applies your conventions. Such a convention for example could be “apply plugin X, and add dependencies X, Y, and Z”. It implements a convention you want to apply to multiple projects, hence the name “convention plugin”.

A convention plugin can be implemented using a normal binary plugin (implement Plugin<Project>, …) in any JVM language, be it Java, Groovy, Kotlin, whatever. But it can also be implemented using a precompiled script plugin. Precompiled script plugins are what you have seen in the example as they are typically used to implement convention plugins. The look almost like normal build scripts with just some slight differences, like you never have a version for a plugin in a plugins block, but you define the plugin as dependency of the project (for example buildSrc or an included build) and then apply it without further version in the convention plugin.

Convention plugins are either put to buildSrc or - what I prefer - to an included build like gradle/build-logic/.

Because you mention buildSrc: Then again there are blogposts that obviously discourage using buildSrc recommend to use a component build

They don’t recommend a component build, but a composite build. (The former has no meaning in Gradle terms) Composite build is what I mentioned with included build. If you have build A, you can include build B as a subbuild. Then build A is a composite build composed of builds A and B and build B is the included build. So yes, I agree with those blog posts to prefer a composite build for example living in gradle/build-logic/, but for some people it feels easier to use buildSrc, both is acceptable.

Actually for repositories I would not put those in a convention plugin but define them in the settings script in a dependencyResolutionManagement block, then it simply works for all projects in the build consistently.

So to resolve plugins you would use a convention plugin and for dependencies you would use a settings script in a dependencyResolutionManagement{} block?

Not for the dependencies, just to define the repositories.
Defining the repositories in the settings script has the advantage that you can set an option to warn or fail if any project-level repositories are defined.
Without this, any 3rd party plugin you apply could define additional repositories and I greatly dislike that bad practice. I want to control from where my project is pulling dependencies, also to prevent having a bad or hijacked repository in there that serves infected dependencies.

If you have dependencies that you want to have in all projects that apply that convention plugin it is fine to add those in your convention plugin.
But often different projects need different dependencies, so often in an idiomatic build, the actual projects only apply 1 to n convention plugins and define the dependencies they need.
But as I said, if you have dependencies needed by all projects applying that convention plugin, just add them in there.

vonSpotz · March 18, 2022, 3:07pm

Hello

Do you mean for the plugins’ repositories?

If yes, how do I then apply a plugin in the subproject, without a version number, as you stated above, if apply is deprecated?

But actually, if the project build paths are inherited by the subprojects’ project classpath, it is not possible not to have the plugin automatically applied to them, if one puts the repository in the plugins {} block in the root projects’ build.gradle?

Probably I am completely wrong again…

Vampire · March 18, 2022, 10:12pm

Do you mean for the plugins’ repositories?

No, normal depency repositories.
Well, plugin repositories too.
But we were talking about normal repositories here.

If yes, how do I then apply a plugin in the subproject, without a version number, as you stated above, if apply is deprecated?

Inside a subprojects or allprojects block?
You don’t there, only the legacy apply works, but using them is discouraged anyway.
Inside a subprojects build script?
Just normal, using the plugins block.
Inside a precompiled script plugin?
Just normal, using the plugins block.

But actually, if the project build paths are inherited by the subprojects’ project classpath, it is not possible not to have the plugin automatically applied to them, if one puts the repository in the plugins {} block in the root projects’ build.gradle?

Having them on the build script class path has nothing to do with it being actually applied or not, just with it being on the class path.
And if it is on the class path, you can apply it without version, or since recently even with version if the version is the same.

vonSpotz · March 20, 2022, 9:00am

Hello

So let me recapitulate. The following is not quite correct. Please tell me where I got it wrong, that would really be nice: The plugins {} block puts the plugin dependencies on the classpath of the root project and of the subprojects. But it doesn’t only resolve the classpath, unless one appends apply false. It also automatically applies the plugin dependencies both in the root project as well as the subprojects. But if one does append apply false then it doesn’t apply the dependenies/plugins on the classpath to the root project and only to the subprojects. Without allprojects/subprojects.

So far, so murky. Also, how does the plugins {} block know how through what repository to resolve the plugin, if it is an external one? Probably the solution is one of the solutions you named?

You say one can apply the plugins without versions in the subprojects, right? So the apply method is not deprecated?

Vampire · March 21, 2022, 6:05pm

The plugins {} block puts the plugin dependencies on the classpath of the root project and of the subprojects.

Yes and no, depends on how technically the answer should be.
It is on the class path of the root project.
The class path of the root project is available in a specific class loader.
This class loader is the parent of the subproject class loader.
So the subproject class loader can find the plugin classes from the parent class loader and uses them.

But it doesn’t only resolve the classpath, unless one appends apply false.

Exact

It also automatically applies the plugin dependencies both in the root project as well as the subprojects.

Here you got it wrong.
It is only applied to the project where you did apply it using the plugins block.

But if one does append apply false then it doesn’t apply the dependenies/plugins on the classpath to the root project and only to the subprojects.

With apply false it is just applied nowehere as the option indicates, but only added to the class path.

Without allprojects/subprojects.

All we talk about should be without them, as they should practically never be used.

So far, so murky. Also, how does the plugins {} block know how through what repository to resolve the plugin, if it is an external one? Probably the solution is one of the solutions you named?

You specify that using pluginManagement { repositories { ... } } in the settings script. If nothing is configured, Gradle Plugin Portal is used automatically. As soon as you specify one repository you have to define all repositories you want, including Gradle Plugin Portal using gradlePluginPortal().

You say one can apply the plugins without versions in the subprojects, right? So the apply method is not deprecated?

Where did I say it is not?
Or well, I never said apply is deprecated, or you would get a deprecation warning by Gradle.
But it is legacy and discouraged.
To apply without version you still use the plugins block, just without a version for the plugin.

vonSpotz · March 22, 2022, 6:23am

Ah ok thanks.

and

And here I actually wanted to ask: “But how do I apply the plugins then?”
But:

Ah ok. So if one has already invokes plugins{} somewhere in the inheritance hierarchy of classloaders / projects before one invokes it a second (3rd & 4th time & so forth is idempotent then I guess?) time, on the second invocation in the classloader descendants it applies them. On the first time it just adds it to the classpath.

Maybe its not classloaders but another concept ? but in general let’s say… “subprojects”?

Another conjecture; The option apply false is then just as deprecated and discouraged like apply?

Thanks

Vampire · March 22, 2022, 7:47pm

Ah ok. So if one has already invokes plugins{} somewhere in the inheritance hierarchy of classloaders / projects before one invokes it a second (3rd & 4th time & so forth is idempotent then I guess?) time, on the second invocation in the classloader descendants it applies them. On the first time it just adds it to the classpath.

… no

If you use plugins { id("foo") version "1" } then the plugin is added to the classpath and thus also to class loaders of the subprojects and is applied to the project where you have that plugins block.

If you use plugins { id("foo") version "1" apply false } then the plugin is only added to the classpath and thus also to class loaders of the subprojects, but it is not applied.

If you use plugins { id("foo") }, the plugin will be applied if it is already available on the class loader, or it will fail if not and is not a built-in plugin like java-library.

Another conjecture; The option apply false is then just as deprecated and discouraged like apply ?

No, see above.
It is used to add a plugin to the class path without applying it.
If you for example apply plugin A in subprojectX and apply plugin A also in subprojectY,
they will live in different class loaders.
Often this is not a problem.
But if for some reason for example subprojectY needs to access tasks or type ATask from plugin A in all projects, then it would not find the tasks in subprojectX as the classes are in a different class loader and thus different classes.
If in that case the plugin would be added with apply false to the root project for example, the subprojects would take the classes both from that parent class loader and thus have the same classes to work with.

Topic		Replies	Views
Plugin with id 'spring-boot' not found Help/Discuss	8	16550	September 5, 2018
Gradle Core plugin isn't loaded from custom repository Help/Discuss	6	3490	January 12, 2024
Gradle Core Plugins (plugin is not in 'org.gradle' namespace) Plugin Portal	8	35625	May 29, 2024
Spring dependency-management gradle plugin doesn't download dependency Help/Discuss plugins	0	469	August 27, 2018
Custom Gradle plugin JAR dependencies are not loaded Help/Discuss plugins	1	1719	July 29, 2018

Why isn't the plugin being loaded in my build.gradle?

Related topics