https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
is there a reason that plugins are defined in settings.gradle and build.gradle? This is resulting in plugins being on the classpath twice (possibly in different classloaders).
e
I am a Gradle neophyte, I will remove the plugin from the build.gradle and try again...
c
all good, so many footguns 😉
🙄 1
e
Nope... that did not help...
c
hmmm. those errors are caused by having the same plugin loaded more than once. Perhaps try with plugins only in build.gradle (have never applied plugins in settings.gradle myself).
v
He does not have them applied in the settings script. The pattern he used is perfectly fine per-se when not using version catalogs. The plugins in 
pluginManagement { plugins { ... } }
are not applied anywhere or added to any classpath. Those just define the default version for the plugin centrally and in the build scripts you can then apply the plugins without version and get the centrally declared one.
What the problem is though it's hard to tell without an MCVE. I think some essential detail is missing.
e
So, it's safe to use 
pluginManagement
in the setting.gradle file?
I am allergic to acronyms, so I don't understand MCVE?
c
v
So, it's safe to use 
pluginManagement
in the setting.gradle file?
yes, nowadays I prefer to use a version catalog, but before I always defined the default plugin versions in the settings script and then used them without version in the build script
✅ 1
e
I need to learn about version catalogues...
👌 1
So, it looks like it was correct to use
Copy code
pluginManagement {
    repositories {
        maven { url "<https://plugins.gradle.org/m2/>" }
        gradlePluginPortal()
    }
    plugins {
        id 'groovy'
        id 'java'
        id 'application'
        id "org.kordamp.gradle.jandex" version "1.0.0"
        id "com.github.johnrengelman.shadow" version "6.1.0"
    }
}
with
Copy code
plugins {
    id "groovy"
    id "java"
    id "org.kordamp.gradle.jandex"
    id "com.github.johnrengelman.shadow"
}
which implies I am dealing with some other problem which I will describe in a new post...
v
Well, it is correct, but partly a bit useless. You add the same repository twice (and that repo is the default if you do not declare any anyway) and declaring the built-in plugins without version in the settings script is pointless too, as there you just declare default versions for plugins in case they are appplied in build scripts without version
e
So, when I removed 
plugins
from my 
build.gradle
file, Gradle could no longer find 
jandex
Clearly, I have no idea how plugins work in Gradle...
v
Of course, I did not suggest that in any way.
Again, the 
pluginManagement { plugins { ... } }
block does only define default version for plugins if they are applied in a build script without version, so that you can centrally declare the plugin versions and then apply them without version in the build scripts.
e
No, you were not suggesting it... that is simply how I feel bashing my head against the Gradle wall...
v
If you don't apply the plugin in the build script, it is not applied
that is simply how I feel bashing my head against the Gradle wall...
Well, what do you expect? If you don't apply the plugin, it is not applied. Seems quite obvious to me. 😄
I have no idea why you "removed 
plugins
from my 
build.gradle
file" 🙂
e
because I have no idea how plugins work in Gradle
c
This is the appropriate config for settings.gradle and build.gradle, respectively.
Copy code
pluginManagement {
    plugins {
        id "org.kordamp.gradle.jandex" version "1.0.0"
        id "com.github.johnrengelman.shadow" version "6.1.0"
    }
}
Copy code
plugins {
    id "groovy"
    id "java"
    id "org.kordamp.gradle.jandex"
    id "com.github.johnrengelman.shadow"
}
✅ 1
e
Yes, that was my guess, so that is what I did, but I still had problems with gradle complaining about versions...
c
yes, suspect there is something else going on. Perhaps a buildSrc or composite build somewhere that is also contributing to the classpath.
✅ 1
e
Yes, I also suspect something else now... and will try to describe it in an new post...
👍 1
v
Yep, that's exactly what I said from the start. 🙂 There is some detail missing that is hard to guess without an MCVE 🙂
e
So, here is some code from one of our files
Copy code
plugins {
    id "groovy"
    id "scala"
    id "java"
    id "application"
    id "org.kordamp.gradle.jandex" version "1.0.0"
    id "com.google.cloud.tools.jib"
    id "com.github.johnrengelman.shadow"
}

apply plugin: 'maven-publish'
why did someone use 
apply plugin
instead of adding it to 
plugins
?
v
Bad Outdated tutorial
e
Did I mention, our Mono Repo is a Big Ball Of Mud?
c
apply plugin
and 
plugins
effect the same result - applying the plugin. As noted, the former is outdated. As to why someone would be inconsistent there, well…
e
We have multiple developers, bashing on our mono repo, and as of yet, I can find none of them are Gradle experts... which is why I am talking to you guys and not my colleagues...
v
Well, Gradle develops in a relatively fast pace. So anything that is best practice today is potentially outdated and bad practice soon. So anything you write outdates and if you copy from some tutorial that is not for the latest version or by someone also not really being a Gradle expert, such things can happen. 🙂
✅ 1
There are a few cases where the legacy syntax is still necessary, but that is definitely not one one of them.
15 Views
Open in Slack
PreviousNext
Powered by