Thank you for helping me understand. For the publishing slowness, there are several action items here:
1. adopting the ATR for processes that can be automated 2. storing the generated documentation that we build in the pre-vote step so it's not regenerated during the later documentation publish step 3. fixing the serial publishing to be async 4. eliminating rebuilds / making use of cache in the forge publish steps (similar to #2 but specific to forge) For build slowness, I've previously mentioned most of these items. Overall, our build isn't slow if you target fast hardware. I understand that's not reasonable for all contributors though, and I believe that James Fredley has several PRs that will address that problem. -James On 2026/09/02 08:45:38 Gianluca Sartori wrote: > 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. > > > > > >
