Do not automatically apply the plugin to all subprojects?

[netvl]

At the moment, if the plugin is applied to the root project of a build, it is automatically applied to all projects. This does not look like an idiomatic thing to do; when applying a plugin to a project, I would expect that only this particular project is affected. Also, this seems wrong in multi-project scenarios when any sub-projects are not Scala or even JVM.

[maiflai]

I don't think there's a requirement that you apply the plugin to the root project of a build.

You should be able to apply this plugin to specific sub-projects if that's what is required.

I do agree that it does automatically apply to sub-projects, but I think this is generally useful and can be worked around as above?

[eyalroth]

This is actually quite the idiomatic behavior for a Gradle plugin.

When declaring the plugin in the main project build file make it not activated by default:

plugins {
  id "org.scoverage" version "3.2.0" apply false
}

Then just apply it in every specific build file:

apply plugin: "org.scoverage"

If you want an example of a full multi module with both java and scala projects you can check out my project.

[netvl]

@maiflai consider the following structure of a project:

• the root project is a Scala project
• a subproject is not a Scala project, maybe not even a JVM language project (e.g. a project specifically dedicated to documentation)

In this case, if I want to use scoverage for the root project, there is only the root project where I can apply the plugin, which would make it automatically enabled for the subproject, which does not make sense at all since it does not need scoverage.

@eyalroth your example has the root project which is aggregation-only, so naturally apply(false) with explicit application in subprojects works. In my example, the structure is a bit different.

This is actually quite the idiomatic behavior for a Gradle plugin.

I don't think any of the built-in Gradle plugins behave this way. Unfortunately, I was not able to find any official guidelines about this, but nevertheless IMO this approach goes against best engineering practices, like the principle of least surprise. Doing things like this also removes some amount of control from the build developer, because there is no way to "un-apply" a plugin. Conversely, it is very easy to apply a plugin to all projects, if there is a need to do so.

Anyway, I personally don't really have any real issue with this behavior right now, it's just something I noticed in one of my builds. If you think there is real value in keeping it the way it is, feel free to close the issue :)

[eyalroth]

I see your point, and I think it's a valid one. Unfortunately, I'm afraid changing this behavior might break existing builds.

As a general Gradle advice, I'd refer from placing any code in the root project and only place configuration and aggregations in it.