Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to removing root project restriction #242

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jsfuchs
Copy link

@jsfuchs jsfuchs commented Aug 1, 2019

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
Copy link

dbolger commented Feb 27, 2024

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
Copy link

dbolger commented Apr 17, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants