Composite build - includeBuild and use within settings.gradle

I’m developing a plugin to be applied to a project’s settings, and am attempting to use a composite build during development.

Including the build works, but it seems I can’t use that same included build within the settings.gradle. It still attempts to find my plugin in a repository.

buildscript {

repositories {
    mavenCentral()
}

dependencies {
    classpath 'com:myplugin:2.0.0'
}

}


includeBuild '../myplugin'
include ':app', ':module'

apply plugin: 'com.myplugin'

I get the error:

Error:Could not find com.myplugin:2.0.0.
Searched in the following locations:

2 Likes

This doesn’t work yet. It’s a bit of a chicken and egg problem because we need to evaluate settings.gradle (which resolves the classpath without included builds) to get the list of included builds.

What does your Settings plugin do? You might be able to get away with applying your plugin via an init script to get around this.

Ah ok I thought that might be the case.

My plugin includes some projects in the build. Can this be done as a Project plugin, or an init plugin?

stumbled upon this:
https://docs.gradle.org/4.9/userguide/organizing_gradle_projects.html#sec:build_sources

The directory buildSrc is treated as an included build

while your answer is absolute correct and matches:
https://docs.gradle.org/4.9/userguide/composite_builds.html#current_limitations_and_future_work

Improvements planned: Making the implicit buildSrc project an included build.

perhaps s.o. with more technical insights can verify this doc

last but not least: to state out: actually it is impossible to move buildSrc to another location than “rootproject/buildSrc”, right?

Hello,

Sorry to revive that thread after so long, but I’ve been looking around for a way to use an includedBuild or even the default buildSrc in my settings.gradle file, and couldn’t find anything more recent :confused:
I’m just trying to use my boilerplate gradle code I use in pretty much every project and although the Project part works like a charm, the Settings part does not.
Are you aware of any progress on this topic ?

Indeed.
Either upgrade or downgrade Gradle. :slight_smile:
Up to 6.0 you were able to use buildSrc classes in the settings script.
From 7.0 on you are able to includeBuild within pluginManagement in the settings script to include a build that contributes Gradle plugins including settings plugins: Gradle User Manual: Version 7.0

I’ve been looking for an example of this and found the following:

After comparing this to my setup, I was missing the java-gradle-plugin, which, theoretically is not required here (I had the right META-INF files), but it must do some magic when including builds. My guess is that it’s this extra gradlew outgoingVariant that only shows up with the plugin:

Secondary Variants (*)

    --------------------------------------------------
    Secondary Variant classes
    --------------------------------------------------
    Directories containing compiled class files for main.

    Attributes
        - org.gradle.category            = library
        - org.gradle.dependency.bundling = external
        - org.gradle.jvm.version         = 8
        - org.gradle.libraryelements     = classes
        - org.gradle.usage               = java-api
    Artifacts
        - build\classes\java\main (artifactType = java-classes-directory)
        - build\classes\groovy\main (artifactType = java-classes-directory)

The java-gradle-plugin

  • applies the java-library plugin
  • adds gradleApi() to api
  • registers the gradlePlugin extension
  • adds some validation for the descriptor files to the jar task
  • adds some tasks and configurations for proper TestKit usage
  • configures the publishing if either of the publishing plugins is applied
  • adds generation of the descriptor files
  • adds a task for plugin validation like missing input and output annotations and so on
  • adds the Gradle version as attribute to the compileClasspath and runtimeClasspath configurations so that multi-version plugins can properly resolve

The first point, applying the java-library plugin, adds the secondary variant you showed.
Though I don’t think that variant should influence whether you can use it in a composite build.

1 Like