I'll create the vote thread then. thanks everyone. On Tue, Jun 24, 2025 at 1:02 AM Mattias Reichel <mattias.reic...@gmail.com> wrote:
> By all means, let's put it in a nested project. > > Den mån 23 juni 2025 kl 22:27 skrev James Fredley <jamesfred...@apache.org > >: > > > After a few conversations with James Daugherty, I think bringing all 6 > > grails-forge subprojects over to grails-core is the best approach for the > > following reasons: > > > > - We are limited on time and need to complete this consolidation before > > the next milestone or release candidate and it take materially less time > > than splitting it in half. Plus Gradle can treat it separately, which we > > already do for grails-gradle-plugins in grails-core > > - Will allow end users that extend forge, for internal app generation, to > > have a simpler, 1 repository path to fork it > > - Over the last year there have been numerous discussions about > converting > > the forge-api project from a Micronaut App to a Grails app and I think > this > > could happen for Grails 8+ > > > > 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. > > > > > >
