James Daugherty,
If you have no outstanding concerns with the gradle plug-in, then I have none. I believe they were addressed in recent days. For grails-data-mapping, I think local builds times for grails-core should also be compared. Local will be substantially faster than github runners, so it is a much smaller concern. James On 2025/04/05 03:06:10 James Daugherty wrote: > I've almost completed all of the coordinate changes. Snapshot builds > should be fully restored once we have > https://github.com/bertramdev/asset-pipeline/pull/376 merged & we merge the > branches I have prepared. > > With that said, after changing these coordinates, it made me realize how > intertwined the views repository really is with core. I haven't seen any > objections to merging grails-views into grails-core. It seems like > everyone has said this is ok so far. I'll leave this for a day or 2 and > then start a vote thread on merging views if no one objects. > > It does sound like people have concerns with data mapping (build times) and > the gradle plugin. James, can you clarify your concern with the gradle > plugin? > > For data mapping, are build times in GitHub the only concern people have? > > Regards, > James > > > > On Thu, Apr 3, 2025 at 2:01 PM James Daugherty <jdaughe...@jdresources.net> > wrote: > > > I am not seeing any objections to grails-cache. I'll go ahead and start a > > vote thread for that one. > > > > For the other mergers, it seems we are still discussing. Here are my > > thoughts: > > > > grails-gradle-plugin - favor as long as we can successfully set it up > > similar to how the views / views gradle plugins worked. > > > > geb - we can't do an `org.grails` release for the older versions so I > > think we can only release with the new coordinates - which means I've > > changed my mind on this and think it can be merged. > > > > grails-views - I didn't realize how many circular dependencies still exist > > between core & views until I started changing the package names. I think > > we should merge into core to ensure it's pulling the libraries built in the > > project. > > > > grails-data-mapping - build times / local workflows are the largest issue > > as James said. I think we have to do this though and we can continue to > > use caching, and lazy task registration to eliminate a lot of this. I also > > think we can make gradle smart enough to not run mongo tests, hibernate > > tests, etc unless a dependent project is changed. There's definitely more > > work to do here. Build hardware would help solve the slower build times > > too. > > > > -James > > > > On Thu, Apr 3, 2025 at 11:37 AM Gianluca Sartori <g.sart...@gmail.com> > > wrote: > > > >> +1 > >> > >> Gianluca Sartori > >> -- > >> Cell. +39 388 1026822 > >> > >> > >> On Wed, 2 Apr 2025 at 19:38, James Daugherty > >> <jdaughe...@jdresources.net.invalid> wrote: > >> > >> > Hi Everyone, > >> > > >> > As we discussed in last week's weekly meeting, we have a desire to merge > >> > grails-cache into grails-core. We want to continue to merge > >> repositories > >> > to simplify our release strategy and reduce the time to publish > >> artifacts > >> > (so we can spend time on developing and not releasing). > >> > > >> > Recall that the current release process works like this: > >> > 1. Pre-release grails core (publish to temporary repo) > >> > 2. Release grails-data-mapping > >> > 3. Pre-release grails core (publish to temporary repo) to pick up data > >> > mapping version > >> > 4. Release grails-views > >> > 5. Pre-release grails-core (publish to temporary repo) to pick up > >> > grails-views version > >> > 6. Release grails-geb > >> > 7. Pre-release grails-core (publish to temporary repo) to pick up > >> > grails-geb version > >> > 8. Release grails-cache > >> > 9. Pre-release grails-core (publish to temporary repo) to pick up > >> > grails-cache version > >> > 10. Release grails-gradle-plugin > >> > 11. Pre-release grails-core (publish to temporary repo) to pick up > >> > grails-gradle-plugin verison > >> > 12. Release grails-profiles > >> > 13. Release grails-core with the included grails-profiles > >> > > >> > Because so many of these repositories refer to other repositories in > >> this > >> > list, these steps ensure the following: > >> > > >> > - We don't depend on a prior unreleased version > >> > - We release all artifacts with a consistent version > >> > - The artifacts do not depend on a snapshot version in their POM. > >> > > >> > Prior to the merger of repositories, there used to be 30+ of these. We > >> are > >> > now down to 7 repositories. This took the release time down > >> significantly, > >> > and it continues to decrease as we merge them. Each step above can take > >> > 10-20 minutes as they are composed of smaller steps not mentioned here. > >> > > >> > Given this overview, and the benefit of simplifying our release > >> process: is > >> > anyone currently against merging grails-cache into grails-core? > >> > > >> > I'm currently in favor of this as I'd rather spend time working on > >> Grails, > >> > not on Grails' Build & Release processes. > >> > > >> > Regards, > >> > James > >> > > >> > > >
