@Mattias what are your thoughts here? I was thinking of starting a vote, and want to make sure everyone agrees.
On Mon, Jun 16, 2025 at 4:00 PM James Fredley <jamesfred...@apache.org> wrote: > 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. > > > > > > > > > >
