Going to a single repository release strategy

[sdelamo]

Grails have used a multi-repository strategy for a long time.

Positives

• Having a repository per plugin allows individual plugin releases without needing a grails-core release.
• Issues and PRs are isolated per plugin. This isolation simplifies triage and plugin maintainability.
• Faster Build times.
• Less Flaky builds.
• Smaller plugins and codebases are easy to contribute to

Negatives

A Grails Framework release is a multi-release process. It involves plugin releases, updates to the Grails BOM (located in grails-core), and a final grails-core release.

• A release often involves a chicken and an egg problem. Grails Core releases an RC (release candidate) version. The plugins release GA (General availability) versions with a transitive dependency to grails-core RC version.
  grails-core BOM is updated with the GA version of the plugins. grails-core is released.

Pitch - moving several plugins into Grails core.

Nowadays, Grails development is not active. Thus, many of the positives of a multi-repository strategy no longer apply. Because of that, many in the Grails Community Steering Committee consider that it would be worth migrating back into the grails-core repository several of the core plugins. Having a fat grails-core will simplify releases of the framework. As doing a Grails release would mean doing just a grails-core release.

I have identified the following candidates:

• grails-async
• grails-views
• scaffolding
• grails-testing-support
• grails-functional-test
• grails-gsp

GORM is decoupled from grails. You can use GORM in a plain SpringBoot or Micronaut application.

However, we should evaluate which, if any, of the following repositories we should consider merging back to core:

• grails-data-mapping
• gorm-mongodb
• gorm-hibernate5
• gorm-neo4j

I want to get feedback from the Grails community. Is it a good idea to merge some of the repositories back into grails-core and archive those merged repositories? What do you think about the list of repository candidates?

[sbglasius]

I think it is important to find the right balance by not giving up on some of the multi-repository plugins, while still moving plugins that are closely related to Grails core into the core repository. Moving plugins that have a circular dependency with the core into the same repository to save time in the build process makes sense.

[jdaugherty]

Some additional insights:

Historically they were combined:

Several of these plugins were originally under grails-core. It makes sense to move them back now that development happens at a slower pace & since the group working on grails is smaller.

Simplifies Development during a time that Grails is facing a major upgrade

If we want to upgrade to Groovy 4, Hibernate 6, Spring Boot 3, etc there are significant package renames in these major releases. It's a lot more difficult to do this upgrade when we have the upgrade spread across multiple repositories that have to be incrementally updated. @davydotcom recently pointed out that grails-core, grails-data-mapping, and grails-async have a circular dependency. While GORM can still be a separate plugin, I think moving to a single source repo makes sense to simplify the next major upgrade.

Going forward, Grails will face these upgrades more in the future

This will be even more important if Grails wants to maintain pace with the latest Spring Boot version since it now has a much shorter supported lifespan: https://endoflife.date/spring-boot .

Simplifies Grails Release Process

To expand on what @sdelamo stated, to release Grails currently, the following has to happen:

• A Release Candidate generated from Grails Core
• Each plugin that needs updated released against that candidate then needs updated and released as GA
• Grails core can then be released

The package renames would be greatly complicated if we have to follow this release structure.

[matrei]

I agree with @sbglasius, there is a balance to be found here.

grails-async for example, is a multi-project build that contains 15 subprojects (11 libraries, 2 Grails plugins, 1 project for functional tests and 1 project for the documentation.

grails-views contains 9 subprojects (7 libraries, 2 Grails plugins, 1 Gradle plugin, 2 projects for functional tests and 1 project for the documentation.

And so on with grails-data-mapping (10 subprojects), gorm-hibernate5 (13 subprojects), grails-gsp (9 subprojects)...

Isn't there a risk we will make the grails-core build/project difficult to manage by pulling in all of these projects.

If this is to be done, is it something that should be resolved before Grails 7?
I feel that the challenges getting 7 released, are big enough, without major project structure changes.
This has to do with maintaining the project going forward, but for that to matter we need to have a project to maintain.

Hopefully package renaming is a rare thing to happen.

[davydotcom]

There are cyclical dependencies that need combined at the least. For example, grails-core needs grails-data-mapping to run tests, grails-data-mapping needs grails-async, grails-async cyclically depends on grails-core. There is most definitely a balance that can be accommodated here. I do NOT believe all of these need to necessarily be merged back in.

[rainboyan]

@sdelamo How does Micronaut handle this? Micronaut 4.0 is also a major release, are there any best practices to share?

[sdelamo]

Micronaut uses a multi-repository strategy as well. The most significant difference between Micronaut and Grails is that in Micronaut Framework, we split the module responsible for publishing the framework BOM (Bill of Materials) into its own repository. That allows Micronaut to publish framework releases without publishing core releases.

[rainboyan]

Thank for your reply.
Yes, I also think it's good practice to use the Platform BOM to manage all module versions. But Micronaut Core also depends on other libraries, such as Micronaut Validation, Micronaut SQL, Micronaut Groovy. It seems like it's hard to avoid circular dependencies between modules.

Unlike Grails, Grails-core plays the role of a framework, and it relies heavily on third-party dependencies such as Spring Framework and Spring Boot versions, and it is difficult to ensure the compatibility of various libraries without rebuilding and releasing grails-core, especially Groovy 3 can cause compilation errors in each minor version.
Grails plugins need to be consistent with Grails on third-party dependencies, so they often rely on the latest Grails Core version to build, especially if the Core API changes.

[sdelamo]

But Micronaut Core also depends on other libraries, such as Micronaut Validation, Micronaut SQL, Micronaut Groovy.

That it is not true. Micronaut core does not depend on any micronaut module.

[gsartori]

I agree the project structure should accommodate a smaller team working on it even if that requires the main project to be fatter.

What I miss in the list of candidate plugins is the Websocket plugin we are using a lot (we are building web GUIs for industrial machines involving serial port and socket communication that trigger UI changes).

Apart from us though, websocket is a standard web technology that, in my opinion, should not be left behind.

[sdelamo]

what is the url of the plugin repository?

[gsartori]

https://github.com/zyro23/grails-spring-websocket

tag: 2.6.0-RC1 is the latest release (2024)

[sdelamo]

That it is a community plugin. That has never been maintained by the core developer team of the framework.

I suggest you contact the plugin developer.

If the developer has moved on and/or has no time to upgrade. I suggest your company forks the plugins and maintains it going forward.

If your company does not have the time or resources to maintain the plugin but you think it is vital for the ecosystem, then I suggest you fund the effort to fork it and maintain it. We recently created a vehicle for supporting Grails: https://opencollective.com/friends-of-grails

[davydotcom]

I actually did a lot of work on this plugin and it is deeply used by myself as well. Rest assured I will be making sure a version of this plugin is updated for 7.0 but it does not need merged into a single repository. A new version of this plugin will simply need released

[gsartori]

@davydotcom do you have any influence on the autor to merge 2.6.0 branch into main? When we visit the github repositoy the plugin looks dead (last update 5 years ago). I wrote a comment to him with no answer.

[rainboyan]

Dependency upgrades and code refactoring are a prerequisite to ensure that tests are not broken.
Of all the modules, the migration to Jakarta EE 9 will have the greatest impact on GSP.
So I think the following modules could be merged first,

• grails-testing-support
• grails-gsp

[basejump]

agree with this @sdelamo, simplify it right now, move the key plugins back in , except for the GORM related ones.