After discussing this further this afternoon, I have changed my opinion from splitting grails-forge in half and am now onboard with bringing the whole grails-forge project over as a sub gradle project in grails-core.
Splitting it in half was convenient for grails development volunteers, but would have made it more difficult for companies forking grails-forge, as their internal custom application generator. It appears the whole project can be merged in a way that makes it streamlined for all. Having a single release workflow, instead of two, is important for release vote approval and review. James Fredley On 2025/06/16 19:28:18 James Daugherty wrote: > I discussed this more with James F to see if we can find other solutions. > I still think we should bring the full thing over. > > Some other thoughts: > 1. I am proposing we merge grails-forge as a sub gradle project to > grails-core only to facilitate easier publishing / building. This means > locally there won't be any overhead if you run ./gradlew build in grails > core. You'll still have to run gradle commands under the `grails-forge` > directory to test forge. > 2. By merging the full repo into grails-core as a nested gradle project, we > will get test coverage end-to-end as part of any PR. (we'll add steps to > build grails-forge & test it). > 3. Any upgrade to grails-forge-core will still have to be made against the > grails-forge repositories. If we split these, we will have the old problem > of having separate repos - publishing in core, only to find out forge is > broken. This was one of the strongest lessons of the grails mono repo. > 4. Anyone wanting to fork forge for custom app generation, will have to > fork core + fork forge to do so if we split it. If we combine into one, it > helps both us and anyone wanting to fork forge since they can just change > the sub gradle project 'grails-forge' inside of grails-core. > 5. Having them both in grails-core means we have almost all steps in a > single release workflow with gated steps to release. The exception will be > the deployment of forge-api itself. > > -James > > > > On Mon, Jun 16, 2025 at 12:37 PM James Fredley <jamesfred...@apache.org> > wrote: > > > I lean towards merging the following 3 project into grails-core to > > simplify the release process and review during the release vote. > > > > grails-forge-core > > grails-forge-cli > > grails-cli > > > > And leaving the following, which are only used for the next.grails.org, > > snapshot.grails.org, etc. instances by start.grails.org in the > > grails-forge repository. > > > > grails-forge-analytics-postgres > > grails-forge-api > > grails-forge-web-netty > > > > James Fredley > > > > > > On 2025/06/15 13:59:15 James Daugherty wrote: > > > Hi Everyone, > > > > > > One of the issues we found as part of our release process is that the > > > projects: > > > > > > grails-forge-core > > > grails-forge-cli > > > grails-cli > > > > > > exist in the grails-forge repo. While they exist in a separate repo > > > (grails-forge), we still have to produce a combined source & binary > > > distribution with these artifacts for any grails-core release. This is > > ASF > > > policy. Having a separate repo complicates the release workflow for > > grails: > > > > > > 1. We have to provide instructions on how to compile both core & forge > > from > > > a source zip. > > > 2. Those instructions ideally use the same build process we use in CI. > > > Since we publish to a shared maven repo, this is currently not possible > > > without a custom build script or change to the local code to publish to > > > maven local. > > > 3. We have to manage a grails release across multiple tags, repos, and > > > workflows. > > > > > > #1 was raised by the groovy PMC as a concern and #2 makes this > > > non-trivial. The concern raised by the groovy PMC is likely to act as a > > > blocker to future releases if we do not address this (it's an ASF > > > requirement). For this reason, I'd like to discuss merging some or all > > of > > > grails-forge into core. If we merge some, it would only be the projects > > > that are used in a grails-core release (listed above). If we merge all > > ,it > > > would include the netty, api, etc projects. Even though these projects > > are > > > only used by start.grails.org. > > > > > > What are people's thoughts on merging? Should we merge all or only the > > > ones we need as part of a grails-core release? > > > > > > For my thoughts: I think merging all of the projects is better because we > > > know some end users fork grails-forge and it would be more convenient for > > > them to fork one repository instead of 2. Basically, by merging > > partially, > > > it makes our life easier, and their life harder. By merging both, we > > keep > > > it simple for everyone. > > > > > >
