I'm not familiar enough with the use cases for third parties forking Grails Forge to assess the strength of this argument.
Do what you think is best. I'm confident it will work out fine either way. Den lör 21 juni 2025 01:17James Daugherty <jdaughe...@jdresources.net.invalid> skrev: > @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. > > > > > > > > > > > > > > >
