I have a bit of problem I trying to resolve for some days. I think it is common usage, trying example from previous post does not seems to work.
This is my directory structure
gradle-release-folder\init.d\init.gradle package this as zip and have the wrapper point to this file
on my build.gradle is empty
When i do gradlew clean build it seems to get the init.gradle ok and build with standard java, groovy and jacoco plugin. However as soon as i put 3rd party plugins, it does not work.
This is the scripts. I did many tries but does not seems to get it working.
settingsEvaluated{setting->
setting.pluginManagement{
repositories{
gradlePluginPortal()
}
plugins {
id "com.diffplug.gradle.spotless" version "6.16.0"
}
}
}
initscript{
allprojects{
buildscript{
repositories {
maven { url "https://plugins.gradle.org/m2/" }
dependencies {
classpath "com.diffplug.spotless:spotless-plugin-gradle:6.16.0"
classpath "com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin:0.42.0"
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.4.0.2513"
classpath "io.freefair.gradle:lombok-plugin:6.6.3"
}
}
}
apply plugin: "java"
apply plugin: "groovy"
apply plugin: "jacoco"
apply plugin: 'com.diffplug.gradle.spotless' //Also try the plugin class name does not work: 'com.diffplug.gradle.spotless.SpotlessPlugin'
spotless {
java {
importOrderFile rootProject.file("config/spotless/default.importorder")
eclipse('4.6.3').configFile rootProject.file('config/spotless/default-formatting.xml')
removeUnusedImports()
target project.fileTree(project.rootDir) {
include 'src/**/*.java'
exclude 'build/generated/**/*'
}
}
}
}
}
Error message:
* What went wrong:
Plugin with id 'com.diffplug.gradle.spotless.SpotlessPlugin' not found.
Actually, it is not common usage.
What you try is actually very uncommon and totally non-idiomatic.
You should not put normal build logic into an init script.
You should put it into convention plugins that you then apply to those projects where those conventions should apply (directly, not using any allprojects { ... } or subprojects { ... }).
But the commonness and idiomaticness aside:
maven { url "https://plugins.gradle.org/m2/" } and gradlePluginPortal() are exactly the same, having both is just redundant and time-wasting
initscript { ... } is like buildscript { ... } just for init scripts. It is used to define repositories and dependencies for the init script classpath. Putting the allprojects { ... } inside it is just decreasing readability and clearness, besides that it would prevent to use classes added to the initscript classpath using the initscript block
similar with the dependencies { ... } block inside the repositories { ... } block, it is a sibling, not a child
apply plugin: 'a.string.here' is for applying a plugin by ID, putting a classname as String there can never work anywhere. What you mean is apply plugin: a.class.Here
to make the latter work, you need to add the class to the initscript classpath using the initscript { ... } block
mavenLocal() is broken by design and should practically almost never be used and for sure not without content filter and not unconditionally added to all builds.
I try to put commonly used plugin, configuration closure in here from what I gather reading the documentation this is the place where I should put the logic. I am facing maintenance issue need to copy and paste in all projects that using the same configuration closure and plugins.
I read some of the examples code in this forum that if I want to put inside allproject I need to use class instead of ID. I try both and it doesn’t work. I had updated the original question script.
I thought you need to put dependencies inside buildscript in order to use the plugins ?
I try to put commonly used plugin, configuration closure in here from what I gather reading the documentation this is the place where I should put the logic.
No it is not.
Init scripts are not really appropriate for defining the normal build logic.
I am facing maintenance issue need to copy and paste in all projects that using the same configuration closure and plugins.
As I said, the proper way for sharing build logic is to write convention plugins that apply your plugins and do your configurations and then apply those convention plugins directly in the projects where those conventions should be effective.
I read some of the examples code in this forum that if I want to put inside allproject I need to use class instead of ID. I try both and it doesn’t work. I had updated the original question script.
Actually, the sheer usage of allprojects { ... } is already bad practice and should not be done.
But anyway, I told you how to use the class name correctly and why it didn’t work, just read my points again and follow them.
I thought you need to put dependencies inside buildscript in order to use the plugins ?
You want to use the class in the init script, so you need to add it to the classpath of the init script. Like I explained in my last comment already.
