Hi Gianluca, My first question is why? Can you please enumerate why you are asking for this change? I'd like to understand what drives it.
As for my thoughts, I'm against merging them for several reasons: 1. splitting the repo adds significant overhead to the release processes. To-date only 3 of us are doing releases, and I don't want to spend time releasing, I want to spend time developing. 2. it encourages stagnation - we saw this in both the security & quartz plugins when they were split and not updated as frequently in Grails 7. This stagnation is both from a development and from a patching perspective. 3. the build time problems are fixable: a. locally we have added flags to already selectively run parts of the build, and I'd suggest we add more if needed b. the github agent times are because the agents are so slow; James F has already contributed significantly in this area, but we really should consider private runners to solve this problem. On "fast" hardware, it's possible to run the build in under 15minutes. c. we need to spend time on the build to support the config cache feature of Gradle, I've been too busy with Grails 8 to do this work but it's on my radar for this fall. 4. Refactoring Grails becomes a lot easier when everything related to the core of Grails is in one repo. We've seen this already in Grails 8 and I think this would have a negative effect on the project velocity if reversed. 5. The plugins often act as functional tests, and splitting the repos will mean more iterations when a change is merged that breaks them. I've lost count how many times this has happened at this point, and the overall Grails releases are significantly better tested as a result of the mono repo. I've spent 1000's of hours due to someone merging a change that they thought was innocent, only to find a downstream plugin/app/test was broken as a result. The lessons learned here are too great to ignore. The amount of time debugging these types of issues is not worth it, when a mono repo eliminates this entirely. 6. the slower publishes are because our current publishing approach is serial. I intend to spend some time fixing this as part of an overall of the Grails Publish plugin later in the fall. On 2026/08/31 19:23:36 Søren Berg Glasius wrote: > Hi Gianluca, > > Ah, so an apache/grails-core-plugins, with non-essential plugins > (spring-security, quartz, grails-micronaut, and perhaps others?) > > It would be interesting to know how the build-time would change vs the > overhead in maintenance, breakage, voting etc. And the one-time migrating > those plugins out of the repo. > > Or if it was better to spend some of our Friends of Grails money to get a > dedicated GitHub Runner? Or have it be funded from elsewhere? > > > Den man. 31. aug. 2026 kl. 12.31 skrev Gianluca Sartori <[email protected] > >: > > > Hi Soren, > > > > In one of the last meetings I remember of a discussion about the increased > > build/release time of the mono-repo. > > > > For sure the number of repos the whole Grails project had before 7.0 was > > too much to handle. > > Maybe now that the emergency has gone and there are tools to handle > > releases quicker, one mono-repo is, again, too much to handle. > > > > I was throwing out this idea of a "grails-core-plugins" with a coupled > > lifecycle. > > If it does not make sense we can just let it die. > > > > "Measure" is a moving thing. > > > > Gianluca Sartori > > -- > > https://dueuno.com > > > > > > On Mon, 31 Aug 2026 at 11:45, Søren Berg Glasius <[email protected]> > > wrote: > > > > > Hi Gianluca, > > > > > > Right now there is https://github.com/apache/grails-core with the > > > essential > > > plugins (maintained by the core committers and the PMCs) > > > Then there are https://github.com/grails-plugins maintained by > > volunteers, > > > but with a tight coupling to the core committers (same people) and > > > finally there are https://github.com/gpc/ plugins that are maintained by > > > the community (among them me) > > > > > > I'm not sure what it is, that you want to split? Right now every plugin > > > from grails-core is in the grails-bom so they follow the core release. > > > > > > There have been discussions if we should make a grails-plugins-bom for > > the > > > external plugins, but I'm not sure what that will bring to the table. > > > > > > So I think you need to elaborate further, what you are trying to achieve. > > > > > > Best regards > > > /Søren > > > > > > > > > Den man. 31. aug. 2026 kl. 10.42 skrev Gianluca Sartori < > > > [email protected] > > > >: > > > > > > > ** This is not a proposal, it's a discussion topic ** > > > > > > > > I was wondering if splitting the repo in: > > > > > > > > - Grails > > > > - Grails Plugins > > > > > > > > could help the release process. > > > > > > > > It would be two separate and sequentials releases but it would keep the > > > > release time slower and it would better decouple the core framework > > from > > > > the upper layer of plugins. > > > > > > > > With Dueuno (open-source) and Dueuno Solutions (closed-source plugins) > > we > > > > are unifing the release version numbers to make it easier for > > > > applications to keep consistency with the two dependencies. > > > > > > > > So the idea would be to keep the release number aligned between the > > > Grails > > > > and Grails Plugins projects (even if it is just a dependency upgrade). > > > > > > > > Does it make any sense? > > > > > > > > ** This is not a proposal, it's a discussion topic ** > > > > > > > > Gianluca Sartori > > > > -- > > > > https://dueuno.com > > > > > > > > > > > > > -- > > > > > > Best regards > > > Søren Berg Glasius > > > > > > Apache Groovy™ and Apache Grails® PMC > > > --- Press ESC once to quit - twice to save the changes. > > > > > > > > -- > > Best regards > Søren Berg Glasius > > Apache Groovy™ and Apache Grails® PMC > --- Press ESC once to quit - twice to save the changes. >
