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
wrote:
>
> James Daugherty,
>
> If you have no outstanding concerns with the gradle plug-in, then I have
> none. I believe they were addressed i
With the group / artifact name changes, we can certainly do that. I would
only want to merge what's considered a "core" release. Spring security for
example should continue to be released separately.
That would include the following:
* Grails-cache
* grails-data-mapping
* grails-views
* grails-g
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,
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
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 plugin
+1
Gianluca Sartori
--
Cell. +39 388 1026822
On Wed, 2 Apr 2025 at 19:38, James Daugherty
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 str
I am in favor of merging Grails Cache into grails-core. This is the right time
do it, since the maven coordinated are changing and on the old coordinates we
were on version 9.0.x which was higher than 7.0.x for grails-core. For this I
think we should have a vote thread just for grails-cache st
@Mattias: the times on that link show that the longest running step was 11
minutes - which is because mongo tests turn off parallel because they use a
common resource. I'm guessing that because we matrix so much that they
can't all run in parallel so it has to wait? Do we really need to test
with
I generally agree with merging repositories.
However, looking at grails-data-mapping, that project alone takes over 22
minutes to build in CI right now:
https://github.com/apache/grails-data-mapping/actions/runs/13873050433
Den tors 3 apr. 2025 kl 14:45 skrev Søren Berg Glasius :
> I agree th
I agree that we should do the bigger merge. Bringing release time down
would help the project, although I know that Gradle build times will suffer.
Den tors. 3. apr. 2025 kl. 14.33 skrev David Estes :
> I agree +1 we should do this!
>
> > On Apr 2, 2025, at 11:51 PM, James Daugherty
> >
> wrote
I agree +1 we should do this!
> On Apr 2, 2025, at 11:51 PM, James Daugherty
> wrote:
>
> With the group / artifact name changes, we can certainly do that. I would
> only want to merge what's considered a "core" release. Spring security for
> example should continue to be released separately.
If merging repositories has so many benefits for releases, why not merge them
all together?
On 2025/04/02 17:35:28 James Daugherty 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 rep
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
13 matches
Mail list logo
