Hi James, mine is not a request or a need. I was thinking about the project build time and probably the little architect within me was also wispering that there are two distinct layers (the Grails stuff and the top layer of its plugins) in the same repo.
The thought was to keep them separate IF that speeds up the whole process of working with the repos - not only the release - but always building them as if they were one and releasing them together with the same version number. I have to say that I was impressed by the fact that we went from "not releasing" to release four (!!) different branches at the same time. I think that Grails has never been where it is today from this point of view. If the cost per release is so low, thanks to the mono-repo and all the amazing work that you all have done, I thought that maybe we could have considered splitting the plugins from the core. That said, I agree with all your points, especially the fact that each plugin is a test case by itself. I can see that phenomenon in Dueuno as well. We have the same concept of a core and many plugins. We are not good with testing automation at the moment (...) so each plugin is a test case by itself. Since we build and release the core repo along with the plugin repo, that works for us. That's why I've shared my thoughts, but that's what they are: thoughts. Not requests or needs. In my experience, stupid thoughts can trigger more intelligent ones, so I don't mind being naive from time to time :) In the end innovation is everything but a linear process. Gianluca Sartori -- https://dueuno.com On Tue, 1 Sept 2026 at 16:40, James Daugherty <[email protected]> wrote: > 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. > > >
