So we distribute our convention plugins via an internal artifactory, but keep them in the same repository for quick iteration, so that when we want to modify them, we just

includeBuild

the directory in our settings script This works fine, however, I want to add all these plugins to the project classpath as such by adding them to the root project build script

plugins {
  alias(libs.plugins.internal.company.plugin) apply false
  alias(libs.plugins.internal.company.otherPlugin) apply false
  // etc
}

When I do this, it works fine until I include the build for local iteration. I basically can’t sync because of the following error

Error resolving plugin [id: 'plugin.name', version: '1.0.43'] > 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.

I’m guessing this happens because when I include the build, gradle seems to add the plugins in it to the classpath with an

unknown

version, but then also tries to grab the latest published versions since I’m also trying to add them to the classpath, thus creating a conflict. Is there any way to work around this or will I have to resort to just commenting out my plugins from the

plugins

block whenever I want to work on them locally?

Having an included build does not add anyhting. Only if you use it, it is build and added as usual. From a cursory look I'd say it should just work fine. If it is not you are maybe hitting some edge case or bug or did not tell some relevant information. Can you steam it down to an MCVE showing the problem?

Yeah, I have the same problem and I don’t use the alias at all. Instead, we add the plugins to the classpath via an includedBuild and apply the plugins via id.

Still, please knit an MCVE. I regularly replace applied plublished plugins by simply adding an

includeBuild

without any problems.

Our setup is exactly the same as nowinandroid. I just noticed they don’t add their plugins to the root project plugins block either, but they don’t publish theirs at all

You already noted two differences yourself and it is a rather big project. That are three significant reasons why this project is useless as MCVE for your case.

I have the same issue as Adam and Philip. In our case we are building our plugin

com.emergetools.android

and we want to test it against another repository as a sort of integration test. https://github.com/EmergeTools/hackernews/blob/main/android/build.gradle.kts We removed our plugin (

com.emergetools.android

) from the build.gradle.kts in the other repository to be able to run this integration test without experiencing the issue that Adam explained.

And here @Adam already reported it yesterday: https://github.com/gradle/gradle/issues/33227 🙂

thanks @Vampire!