Allow applying the plugin to a non-root project #359
Conversation
This introduces the idea of `independentProjects`, defaulting to false, and limiting application of the plugin to just the project applied to if it's true. By itself, this change should allow projects with a single subproject (such as is templated by `gradle init`) to apply the plugin to that project only. It's also laying a little ground-work for cross-project synchronisation of staging repositories that's compatible with isolated projects.
| require(project == project.rootProject) { | ||
| "Plugin must be applied to the root project but was applied to ${project.path}" | ||
| } | ||
| val isRoot = project == project.rootProject |
There was a problem hiding this comment.
I wondering if this change alone is enough? If the user applies to non-root, then it implicitly start using the independent mode? Since it was not allowed before, it means we can define any behaviour for that case.
There was a problem hiding this comment.
Up to you -- I didn't want to break any of your existing tests.
Also, I'm not sure what would happen if someone tried applying the plugin to multiple projects in a build. I suspect it won't work properly; I'm pretty sure it'll open multiple staging repositories. So I wonder if needing to specify an "incubating" property is useful as an indication that the behaviour might not be entirely stable?
There was a problem hiding this comment.
Having the plugin applied multiple times in the project might sometimes be useful for monorepos which (for some reason) would like to release particular projects to different locations in Central. However, the project author would then need to ensure that group/project/version is property set in that (sub)project and probably some other element which the plugin gets from the project.
Looking at some comments in #81:
Moving the plugin to the root project also implies declaring all the publishing etc in the root project and that would mess up all the configurations I have, basically giving up on isolation.
That's not entirely true. You only need to configure nexusPublishing in the root project but can continue declaring your publications in modules:java.
And:
#81 (comment)
I originally made it a root project plugin so there's a single place to configure Nexus repositories that are shared across subprojects. While each subproject has an "init" task, they use a resource attached to the project to synchronize on to ensure a shared staging repo is created. This could probably be changed to create a checksum of the repo config or require some kind of identifier and a BuildService but I lack the time to give it a try.
I'm a little afraid to add that switch and later on have an another set of issues related to "corner cases" 🤔
I have no experience with build_services. Do you? How hard would it be to convert the plugin to it? Would it "fix" all the (related) problems?
There was a problem hiding this comment.
I've been pondering the question of how I'd go about turning this into a build service -- I do have some experience with them, but not of the degree of complexity that this plugin might require if we wanted to minimise surprises for existing users who upgrade.
There are some design questions that we'd need to decide on answers for. I'm not sure I have all the questions yet, let alone the answers.
If you'd be interested in seeing the result of my attempt to refactor a bit more thoroughly (with absolutely no obligation to accept any of my code, or indeed any of the design choices I might make) then I'll probably quite enjoy the diversion. I'm yak shaving for a personal project, interesting problems are if anything more what I'm looking for than actual solutions :).
This introduces the idea of
independentProjects, defaulting to false, and limiting application of the plugin to just the project applied to if it's true.By itself, this change should allow projects with a single subproject (such as is templated by
gradle init) to apply the plugin to that project only. It's also laying a little ground-work for cross-project synchronisation of staging repositories that's compatible with isolated projects.This PR is in response to #81 but is not a complete solution.