Composite gradle build: spotless works in one project and not in another #860
Labels
Comments
|
I have created a very simple repro of this problem here: spotless issue. Now I uncomment any of the other plugins. For example, in I would appreciate any help understanding what is going on. |
|
3.27.2 was a long time ago. We've had two very small breaking changes since then (4.x and 5.x), both were required for us to stay compatible with latest Gradle, and required no changes for most users, but a small change for some users. Gradle has made lots of composite build improvements in newer versions too, so I'd say updating to latest would be a good starting point. We are admittedly doing something weird with |
|
Thanks so much for getting back to me! I tried version 5.13. Unsurprisingly, the problem is still there. I am not gradle-savvy enough to fully understand the provided link. Is the issue simply two projects trying to register spotless with the root project, or is it two projects with different buildscript dependencies trying to register? I think it is the latter. I am guessing that using different plugins will cause different buildscript dependencies, even if all specifically listed dependencies are identical. At this point, I think that my choices are:
|
|
The root project has special privileges w.r.t. resolving dependencies, which we abuse through the special I think that in a composite build, each builds gets its own classloader so that the builds can have different versions of the same plugins without conflict. So one workaround would be for this task name to somehow be composite-build aware and use its own unique name, so that each build would get its own task. Maybe the taskName could be That would be a relatively easy fix. In the long-term we'll get away from resolving all dependencies in the root project someday, but I don't think that will happen anytime soon. |
|
@nedtwigg Are there any plans to make the proposed easy-fix changes? Or are there any workarounds I may have missed? We'd love to leverage Spotless for a few projects, but a requirement is for it to support multiple subprojects. |
|
Two things I have learned. First, this is not only a problem with the spotless plugin. Other plugins have a similar problem where inconsistent definition across subprojects fails. Second, I have been able to get things to work by making a convention plugin that each of the subprojects apply. You can see what I did here. |
Perfect! Was happy to adopt the conventions approach, and can confirm we reproduce success with this approach of applying plugins to multiple subprojects. Thanks! |
|
I expect this will get fixed by
They are sitting in the review queue, I'll post again when 6.0 is released and ready for testing. |
|
I believe these issues are all resolved in plugin-gradle 6.0.0, see release notes for details. Please reopen if the issue re-appears. |
|
@nedtwigg Unfortunately, I still got this error on 6.0 |
|
The error is happening at this line: It appears that the following things are true:
A workaround would be to catch taskName = RegisterDependenciesTask.TASK_NAME + System.identityHashCode(RegisterDependenciesTask.class)That would let each classloader have its own |
ervinpm
pushed a commit
to ervinpm/spotless
that referenced
this issue
Nov 24, 2021
ervinpm
pushed a commit
to ervinpm/spotless
that referenced
this issue
Nov 24, 2021
ervinpm
pushed a commit
to ervinpm/spotless
that referenced
this issue
Nov 24, 2021
nedtwigg
added a commit
that referenced
this issue
Dec 7, 2021
|
Fixed in |
tueda
added a commit
to tueda/donuts-python
that referenced
this issue
Dec 7, 2021
The "composite gradle build" issue of Spotless was fixed in 6.0.4 (diffplug/spotless#860).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary:
I have a composite build with three projects. In one project, the gradle config with spotless works. In the second project, I get this error:
Gradle version: 7.0
Spotless version: 5.12.4
OS: Mac BigSur 11.3.1
I am running within IntellJ Community 2020.1
I am in process of restructuring the build. You are welcome to look in Terra Workspace Manager at the branch
dd-PF-259-messwithEach project has a build.gradle. The top level has a settings.gradle and a build.gradle. The only purpose of the top-level build.gradle is to hold a repository declaration for spotless. It cannot seem to use the project-local repository configuration.
I tried to create a simple case that replicated the build structure without the code, but that worked just fine.
In the broken project, the setup is:
In the working project, the setup is:
Gradle stacktrace:
The text was updated successfully, but these errors were encountered: