This message was deleted.

My suggestion would be to not use mavenlocal, but instead use a composite build to try out your plugin.

I usually use composite build... you can see the

includeBuild

commented there... but composite build does not support settings plugins

that's not right, it does support settings plugins

I am using

`maven-publish`

and running the command

./gradlew publishPluginMavenPublicationToMavenLocal

which I understand to publish the artefacts in my local maven repository...

I'm confused. It's complaining about a different plugin though 🤔

that plugin is part of the convention plugins project that I am working on.

so there's something else wrong, it's not the composite build at fault here, right?

well, if I use composite build, I can't use the settings plugin because of this error... it seems I was wrong in understanding that Settings plugins are not supported in composite builds

Can you just remove the version from the

android.application

plugin and see if that works?

I am not adding

alias

to my root

build.gradle.kts

file as I am declaring the configured plugins like this

implementation(libs.gradlePlugin.android)

so I can bind AGP version with a version of the plugin itself.

so in your settings plugin, you depend on a version of the android.application plugin, right? In the consuming project, are you also applying that same android.application plugin? If so, does it come with a version specified?

no, my settings plugin does not depend on AGP, but my "convention plugins" project does. As such, the client project does not declare anything related to AGP...

It is wrong that composite build does not support settings plugins.

yes, I kind of got that from the other plugin's id 😛 it's that one that's throwing the error, not the AGP plugin, so I'm not sure why you keep bringing that one up?

It is one of the reasons that

includeBuild

within

pluginManagement { ... }

was added, exactly for the use-case, that an included build can provide a settings plugin

Ok, got it. I was wrong.

The error you posted said something about

apply false

so I think it is a different place it complains about, not the application through the

plugins { ... }

block

I'm assuming somewhere in the client project there's

id("com.veepee.kotlin.android.application") version "0.2.3" apply false

And your convention plugin is bringing in that same plugin through the composite build. My point was to remove the version from that plugin to try if that circumvents the problem you're seeing. I believe I caused some confusion by not spelling out the entire name of your android.application convention plugin. I'm not an android developer, so I wasn't aware that there's an actual plugin out there with id exactly

android.application

🤷

OK, I published a version with

publishToMavenLocal

, commented my

includedBuild

and tried to apply my settings plugin.. The result is that I still have the error

Error resolving plugin [id: 'com.veepee.kotlin.android.application', version: '0.2.3', apply: false]
> 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.

if I remove

plugins {
    alias(libs.plugins.veepee.kotlin.android.application) apply false

from my client project... it will go complain in the place where I apply the plugin with the same error.

so what does that apply look like?

regular ?

plugins {
    alias(libs.plugins.veepee.kotlin.android.application)
    alias(libs.plugins.veepee.flavors.android.application)
    alias(libs.plugins.veepee.android.test.android.application)
    alias(libs.plugins.veepee.flank.android.application)
    alias(libs.plugins.veepee.publishing.android.application)
    // alias(libs.plugins.veepee.crashlytics.android.application)
    alias(libs.plugins.veepee.compose.android.application)
    alias(libs.plugins.veepee.dagger)
    // id("com.google.gms.google-services")
}

yeah, this seems like a very complex setup to try and debug as a black box to be honest 🤔 I would try and reduce it down as much as possible...

Yeah, if the plugin comes in already and you try to apply it again with version (which

alias

is doing), then it only works if Gradle knows which version was brought in to the classpath, otherwise you get exactly that complaint you posted. Apply it without version and it should work.

Ok, trying...

Feel free to add your feedback on those linked github issues. Glad you could make it work 👍

Being able to use version catalog in settings script will not happen due to hen-and-egg problem. The feature is designed in a way so that settings plugins can contribute a version catalog. So you cannot use a version catalog to apply a settings plugin as the version catalogs can only be available after the settings plugins were applied. But besides that, it would not change anything. If you for example add a plugin to the settings script classpath, for example by applying it, it is in the class loader of the settings script. This class loader is the parent class loader of the build script class loader. The class loader does not have information about which plugin versions were added to it, so the compatibility cannot be checked, no matter which way you added the plugin to the settings script classpath.

what would be the correct way to solve the issue in a way that we don't have to revert to

id

? To me, n00b, in gradle, it seems that gradle is mixing it's infra with the infra it offers to it's users...

The class loader can also not really know which version of a plugin was added to it. Theoretically plugin X in version Y could be in code artifact Z of version A. The actual reliable plugin version is just contained in the marker artifact and that does not even really have to be used to add the plugin to the classpath. So it is unlikely that this will ever change, unless plugins in future are forced to provide some standardized means to get their version in use somehow.

yes, that is my exact context, I thought about splitting it in two projects. I will explore that after I am back from my vacations that starts in a few hours 😛

You might want to then add a check that the versions are in sync, for example have the version in a class in the common artifact and in a class in the build plugin artifact, then compare those versions when a project plugin is applied. Due to the classloader hierarchy the common class used would always be the one from the settings class loader, so you cannot use the version from the common artifact in the comparison for the project artifact version.

You lost me when you started talking about classloaders... Any sample project?

Unfortunately not. But you can ignore the part about the classloaders, that was just explanatory, and just do exactly what I said if you want to ensure the version is the same. 🙂