This message was deleted.
# community-support
s
This message was deleted.
c
publish it with
compileOnly
, which requires the consumer to provide an implementation of their version choice.
j
yeah I know that is possible but I want to keep it as
implementation
as changing the kotlin version is an exception in tons of projects which would lead to force me to apply the kotlin plugin in all of them
c
ok. not aware of another option. perhaps something in the buildscript block to force dependency versions.
j
I tried the common way of setting it in dependencies + classpath but nothing :/
I have even tried to move it to
compileOnly
in local for a time until I found a different way, but looks like it is being added to the classpath too, not sure how, maybe transitively from other plugin? Anyway, still looking for an alternative to remove a plugin from the classpath to readd it with a different version, or override the version if possible
The stacktrace is
Copy code
* What went wrong:
Error resolving plugin [id: 'org.jetbrains.kotlin.jvm', version: '1.9.20-dev-5788']
> 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.
v
You bring in 1.9.0 through the settings plugin which then means it is in a parent class loader of the build script class loader and then gives the "unknown version already present" problem: https://scans.gradle.com/s/steqwiiog7p5m/build-dependencies?dependencies=kotlin-gradle-pl&expandAll&focusedDependencyView=details Assuming your settings plugin does not actually need the KGP, I guess an option could be to split the settings and project plugins into separate artifacts, so that the settings plugin does not have a KGP dependency.
thank you 1
j
Yeah, indeed I am doing what you can see in the image, and that brings me another question, if I split them in two different artifacts, but I create a common one which pick both as
implementation
in order to do the same you see in the image, I will get the same issue, right? So, should I keep my common module without any
implementation
and apply the plugins by ID or something so?
v
You probably just cannot have one ID for both in that case but need different ids for the settings and project plugins. But first test out whether that would actually solve your problem
j
Both have different IDs now, the other one is just applying them by class, but under the hood they would use a different ID
Really thank you, I will try and will submit conclusions here
v
Yeah but to apply by class you need a dependency and by that have KGP again. At last the settings plugin should be applied by concrete id to have a chance most probably
j
but I can apply by id and that would work no?
v
No
You would still need the dependency
j
That can be problematic if it is applied to this too: My settings plugin is applying the project plugin to all projects
Copy code
private fun Settings.useHubdleOnAllProjects() {
    gradle.beforeProject { project ->
        if (hubdleSettings.useOnAllProjects.get()) {
            project.pluginManager.apply(PluginId.JavierscHubdleProject())
        }
    }
}
v
Then you might be f*****, no idea 🙂
j
First approach you have right, my plugin is not found
Copy code
An exception occurred applying plugin request [id: 'com.javiersc.hubdle', version: '0.6.0-SNAPSHOT']
> Failed to apply plugin 'com.javiersc.hubdle'.
   > Plugin with id 'com.javiersc.hubdle.settings' not found.
I can put the settings one, but I will report what happens with the use on all projects part....
It is not found so I must apply the hubdle plugin individually to each project 😞
I guess there is no workaround with something like
compileOnly
and so on right? It is annoying losing the ability to not only share the ID, being unable to apply the plugin to all projects without breaking project isolation by doing that in the root project, something I will not do...
Anyway, I am getting issues as the Kotlin version I want is a dev one which collides with SqlDelight, Molecule and more plugins, so I think it is just easy to maintaining a double publication of my plugin with the current stable Kotlin version and a dev one
v
Of course
compileOnly
would help, but then you depend on the consumer providing the dependency which you also said you don't want to.
You could maybe have a veriant with
implementation
for the cases where you do not want to have a custom version and a variant with
compileOnly
so that the consumers that need a different version can provide it by using that variant.
j
Yeah, but I would need to have different settings plugin too, I will check all trade offs, any way, really thank your your help!
👌 1