I am not seeing any objections so I'll move forward with a vote thread for views & grails-gradle-plugin.
On Sat, Apr 5, 2025 at 12:36 PM James Fredley <jamesfred...@apache.org> wrote: > > 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 > > >> > > > >> > > > > > >
