This is not yet possible. The plan is, to change the behaviour here, that the buildSrc project can be any project of your multiproject build. this will also allow relocating your buildlogic into a customized directory. Though, I can't promise you any timeframe within this will be implemented.

Is there any news about this?
Could I contribute to that?
It looks a bit like the SettingsHandler uses the BaseSettings.DEFAULT_BUILD_SRC_DIR hardwired which should be made configurable, but i guess there is more that needs changing.

@max, it's a pretty deep change, but if you want to help tackle it, that would be great.

One issue here is that the output of buildSrc is made visible to the settings.gradle script, so it's too late to configure this in the settings.gradle - which is where the setting belongs. There are a bunch of other issues with the buildSrc project and we want to replace it with a more general and flexible solution.

There are two potential ways of solving this, and eventually we want to provide both options.

The first is to give you some way in the settings.gradle to reference another build and to make the outputs of that build visible to the projects of the current build. This is a generalisation of the buildSrc concept, and instead of customising the location of buildSrc, you're adding another build instead as a replacement for buildSrc. This approach also allows you to aggregate otherwise independent builds into a single logical build.

The second option is to give you some way to declare a project dependency in a build script, so that the output of the referenced project is built before the referring is configured. This approach makes the buildSrc project just a regular project in the build. It means you can both publish and use a plugin from the same build (but not the same project - at least not yet).

These are both pretty big changes, but we can break it up into some small pieces and implement it incremental. If you're interested, perhaps let us know on the dev mailing list.

One simple solution/workaround I'm using is to symlink the desired directory to "buildSrc". Example:

multiproject
|- build.gradle
|- settings.gradle
|- buildSrc -> gradle-plugins
|- project
|  |- build.gradle
|  \- src/main...
\- gradle-plugins
  |- build.gradle
  |- settings.gradle
  |- plugin-a
  |  |- build.gradle
  |  \- src/...
  \- plugin-b
     |- build.gradle
     \- src/...

Where gradle-plugins is isolated from the rest of the build (i.e. not referenced in multiproject/settings.gradle). Also:

subprojects {
    apply plugin: 'groovy'

    dependencies {
        compile gradleApi()
        compile localGroovy()
    }

    rootProject.dependencies {
        runtime project(path)
    }
}

And:

apply plugin: "YOUR_PLUGIN_ID"

...

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.