Error: plugin already on the classpath must not include a version

I’m trying to create a multi-project build. I get this error:

* Where: Build file '/Workspace/SubProject/build.gradle' line: 14
* What went wrong:
  Error resolving plugin 
    [id: 'kotlin-multiplatform', version: '1.3.31', 
     artifact: 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.31']
> Plugin request for plugin already on the classpath must not include a version

The offending lines from the subproject’s build file are:

plugins {
    id 'kotlin-multiplatform' version '1.3.31'
}

The error makes sense, but I’d like to be able to run my subproject by itself, so how can I specify the kotlin-multiplatform plugin in a way that says: “Use version 1.3.31, unless you’re running as part of a parent project, in which case the version is defined there.”

Rob

2 Likes

I too want to do this, except the plugin that I’m interested in is spotbugs instead of kotlin.

I didn’t find any reference to this use case in Grade plugins documentation.

I also had an issue where a Gradle project could be built as standalone or as a sub-project of another Gradle project and I wanted to apply sonarqube in the sub-project as well as the root project.

Currently, I can think of 2 “workarounds”:

  1. In your sub project, instead of applying with the plugins{} block, apply the plugin conditionally using legacy plugin application. This is the method I used:
buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.31"
  }
}

def kotlinPluginId = 'org.jetbrains.kotlin.multiplatform'
final hasPlugin = project.getPlugins().hasPlugin(kotlinPluginId);
if (hasPlugin) {
    final Plugin plugin = project.getPlugins().getPlugin(kotlinPluginId)
    println 'Plugin already applied - version ' + plugin.properties['kotlinPluginVersion']
} else {
    apply plugin: "org.jetbrains.kotlin.multiplatform"
}
  1. Create a dummy root project for the standalone project and use plugins{} block there for the sub-project. In this case the sub-project won’t have any logic to apply the plugin.

I hope this helps or gives an idea how to approach this issue.

1 Like

This works, it would be great if I didn’t need this chunk of code and gradle could just figure it out. But such is life.

I found on https://docs.gradle.org/current/userguide/plugins.html
that for me this problem is solved by Example 8 by specifying the plugin version to use hence forth. The version can be omitted in both Gradle 5 and Gradle 6 using that method, providing some backwards compatibility.

settings.gradle.kts

pluginManagement {
  val helloPluginVersion: String by settings
  plugins {
    id("com.example.hello") version "${helloPluginVersion}"
  }
}