The point of this vote was to prevent having to comment out spring security when we do major upgrades & consolidate to one repository. If we're going to kick that can down the road, I'm not sure we should merge it (my vote was contingent on this).
To my knowledge, it's only spring security that's included in core. Also, because it's included in our project, our solution for major changes had to be: comment the project include out. The purpose of merging to a single repository is so we can change it all at once and not leave tests in a broken, unrunnable state. This is the #1 lesson learned I had from our original Grails 7 development & from our ASF merge. A mono repo only works if you can work on the code together with incremental changes and testing. Otherwise, let's say we make a major plugin change (which we have explicitly talked about doing), we suddenly can't run the tests because Grails Mail uses the older plugin contract. We could alternatively abandon Grails Mails in our tests and I'd be happy with that solution. What I don't want is to include a project that depends on Grails that then prevents us from changing Grails unless we disable the include. This often results in the test staying disabled for a long time, and when we re-enable it, something is broken that we didn't expect. This has been a source of huge time syncs in the past. On Fri, May 29, 2026 at 4:46 AM Mattias Reichel <[email protected]> wrote: > > But we already have some dependencies that are only used in test apps, > could not grails-mail be added to this list? > > In gradle.properties: > > # Libraries only specific to test apps, these should not be exposed > ersatzVersion=4.0.1 > grailsSpringSecurityVersion=8.0.0-SNAPSHOT > jbossTransactionApiVersion=2.0.0.Final > > Den fre 29 maj 2026 kl 00:45 skrev James Daugherty via dev > <[email protected]>: > > > > Because of how the gradle dependency resolution works, it would very likely > > break or cause core to depend on an external change. This is why I viewed > > it as a must. If the tests removed the plugin, it could be removed. > > > > On Thu, May 21, 2026 at 2:57 AM Mattias Reichel <[email protected]> wrote: > > > > > I think grails-mail is only used in functional tests, so I'm not sure > > > that grails-mail needs to be merged into grails-core. > > > > > > Den ons 20 maj 2026 kl 20:25 skrev James Fredley <[email protected] > > > >: > > > > > > > > Before we create a vote thread to consolidate grails-spring-security > > > into grails-core, grails-spring-security depends on > > > org.apache.grails:grails-redis and org.grails.plugins:grails-mail and > > > given > > > the policies we apply to grails-core, I think both of those would have to > > > be merged into grails-core, also. > > > > > > > > Agree or disagree? > > > > > > > > James > > > > > > > > On 2026/05/18 12:04:43 James Daugherty wrote: > > > > > We briefly discussed this on the weekly, but I thought this deserves > > > its > > > > > own thread: I would like to propose we merge grails-spring-security > > > into > > > > > grails-core and its associated dependencies (means grails-redis). > > > > > > > > > > The reason we did not merge these before was the security build often > > > hung > > > > > and took 2+ hours. Recently Mattias has worked to make that more > > > stable. > > > > > It’s now running in 1-2min. > > > > > > > > > > We also have not done the best job releasing dependency updates on > > > > > this > > > > > repo and by moving it into core we can ensure timely updates. We can > > > > > also easily identify dependencies that should really be in the bom. > > > > > > > > > > I would propose we move the 7.0 branch into 7.0.x so we can cease all > > > > > activity on spring security. > > > > > > > > > > What do others think? > > > > > > > > > > -James > > > > > > > >
