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