Trying to removing root project restriction

[jsfuchs]

I'm opening this up more as a conversation starter than a change to be put in immediately.

Where I'm working, I really want to apply the gradle lint plugin inside a mono-repo. Applying the plugin at the root level is just not feasible - it takes far too long to analyze the whole root, and I wouldn't even be able to apply most of the fixes because I only work on a very small bit of the whole repository.

So here's my attempt at removing the restriction. I'm definitely not understanding why it was there in the first place (e.g. what bugs have I uncovered by removing this restriction?).

My initial testing with the modified plugin has been successful so far. I was able to apply it to a subproject and the analysis I get is only for that subproject.

[dbolger]

Is there any consideration for this proposal today? While our structure isn't the same as @jsfuchs, our subproject build.gradle files would benefit from applying this plugin to help reduce noise in our root build.gradle files and allow for customization of rules/exclusions in each subproject.

This may not be a trivial change for projects that already apply it at the root-level. Maybe a backwards-compatible solution could be implemented to ensure that support for those projects is not lost.

[dbolger]

I went through trying to remove the root project limitation yesterday, and I've been able to lint successfully. @jsfuchs changes seem to have worked at least for task creation, however, another change was needed in the FixGradleLint task to apply the changes in the lint.patch file to the project.rootProject.projectDir, instead of project.projectDir (since project.projectDir was previously the root project's directory). I think no matter where we reference project.rootProject.projectDir, say from a submodule or the root itself, this will always resolve to the same location, meaning backwards-compatibility should be kept, since previously, project was rootProject. I think we'll want to only create the lint tasks if we're applying the plugin to the root (like the current logic) or if the root project doesn't have the plugin, since at that point, a submodule is applying the plugin, and it should have it's own set of tasks.

Further, Gradle's documentation today states that cross-project configuration should be avoided and this is one place we'd like to avoid it in our buildscripts, if possible: https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins_vs_cross_configuration

@rpalcolea Do you have any thoughts on the above?