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. > > >
