https://gradle.com/ logo
Join Slack
Powered by
hey folks, when I update my sample project to use ...
# community-support
j
hey folks, when I update my sample project to use gradle 8.11.1 in a composite build with my plugins (one settings project and another plugins project) I am getting this error
Copy code
What went wrong:
Error resolving plugin [id: 'com.veepee.kotlin.android.application', version: '0.4.14']
> The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.
on version 8.10.2 it just works, any ideas of how to debug it ? Is this a known issue?
v
Not heard of it so far. Can you knit an MCVE?
m
What it says on the tin, something is bringing that plugin transitively onto your build classpath
It's surprising that this works on 8.10.2 and not on 8.11.1
any chance you could publish a build scan from 8.10.2 and share?
v
Optimally from both versions I guess
But afair that specific error is in most cases not discoverable by build scan
j
I tried to reproduce in a small project that I could share... but I couldn't reproduce... here is the ./gradlew clean --scan in the sample project of my plugins repository https://scans.gradle.com/s/r5znpnh6gx5kc
I can't run the --scan after the update because of the error...
v
Ah, right, of course, plugin application fails, sorry. 🙈
j
I know it is not great, but if I remove the includbuild for my plugins... I can run the --scan, maybe it helps..?https://scans.gradle.com/s/ha5lhdastk7ra
m
how is 
com.veepee.kotlin.android.application
plugin defined?
is it in one of the included builds?
j
yes, I have many plugins defined and one of those is that one.. on the root build.gradle.kts
Copy code
alias(libs.plugins.veepee.kotlin.android.application) apply false
used in the app build.gradle.kts
Copy code
alias(libs.plugins.veepee.kotlin.android.application)
libs.versions.toml
Copy code
veepee_kotlin_android_application = { id = "com.veepee.kotlin.android.application", version.ref = "veepee_gradle_plugins" }
m
why are you adding the plugin to classpath of the root build script but not applying it?
i.e. why do you use 
apply false
?
does replacing 
alias(libs.plugins.veepee.kotlin.android.application)
with 
id("com.veepee.kotlin.android.application")
in the app build script work?
v
Do you also have settings plugins from that build? Or are you also using 
buildSrc
?
j
because that plugin is meant to be applied in a particular module, by declaring it in the root file I set the fixed version..
it seems that if I use 
id
I can't use the version catalog definition...
yes, I also have a settings plugin in another project
m
Sorry but I don't understand
because that plugin is meant to be applied in a particular module, by declaring it in the root file I set the fixed version..
What do you mean by that?
j
I have • convention plugins • settings plugin • sample project that depends on both
m
Why do you use 
apply false
in the root build script?
j
because the plugin is not meant to be applied at that module
m
so why does it need to be added as a dependency?
to that module?
j
to have a fixed version of it for the whole project
m
oh, I see
now it clicked
Not sure why it worked prior to 8.11.1 but I would expect your setup to fail from my own experience
if you add a plugin to the classpath of the build script of a project (app) by adding it to the classpath of a parent project (root) then you no longer can apply that plugin with version as it's already on the classpath but gradle cannot tell in which version
j
it works just fine if I don't use composite builds and use the binary versions
the issue happens only with composite builds
m
if you really want to apply it to the root project (I find your reasoning odd that you are doing it for enforcing a version if you also use a version catalog) and still want to apply using an alias then I would suggest creating a second, versionless alias
Oh, interesting, I did not know that it works fine without composite builds
I dunno, I personally wouldn't add the plugin to the root project if you also use version catalog and aliases for all plugins and your problem would go away
🤷
but sounds like a possible bug/regression
if it used to work fine
and it doesn't work only when composites are invovled
v
That you cannot apply with version is outdated information actually. 🙂
til 1
That was like that long ago.
Now if it is the same version, you can apply or add to root build script and apply with version in the subproject as long as the version is the same and is known by Gradle
The problem is, if Gradle does not know the version because it for example comes in via 
buildSrc
dependency through parent classloader, or I think also maybe if it comes in through a settings plugin to the settings classpath.
If you split up your convention plugins so that the project plugins are in one project, the settings plugins are in another project, it might start to work.
If that's not the case, there is not much that can be said without an MCVE or the actual project
j
it is like that today!
I use `includeBuild`for the project plugins and another 
includeBuild
for the settings plugin
I will try to create a MCVE...but even that takes a lot of time
v
You could try to remove the 
com.veepee.kotlin.android.application
application and then create a build scan, maybe then there it is visible where it comes from 🤷‍♂️
j
There are like 10 plugins... If I remove one... The next one will appear as the problematic one
4 Views
Open in Slack
PreviousNext
Powered by