+1
Den lör 22 mars 2025 05:25James Daugherty
skrev:
> Michael: can you give a reasons to why you disagree?
>
> On Fri, Mar 21, 2025 at 11:00 PM Michael Yan wrote:
>
> > [-1]，specifically, I disagree with 1, 2, 10
> >
> > On Sat, Mar 22, 2025 at 6:02 AM James Daugherty
> > wrote:
> >
> > > Hi E
eally a
> relational mapping anymore. That's why we've changed the name to
> grails-data in the artifacts. This matches other project conventions such
> as spring-data & micronaut-data. Long term, we may want to even 'gorm'
> from being used and simply refer to it
27;s
> > easier to read. Also, we got rid of the additional prefixes so we'd only
> > ever have the format `grails-X`. If we had prefixes to group them
> > together, I'd agree, but since we don't, why not make it easier to read?
> >
> > On Fri,
We are getting there!
A couple of more thoughts and suggestions on the last iteration (
https://github.com/jdaugherty/grails-core/blob/3b4da92e339b7b688011e4a8ffc3c2aaea723680/RENAME.md?plain=1
):
1. As we are working with groupings, I think we should consider collapsing
some group parts in the
Maybe a silly question, and sorry if I have missed a previous discussion
about this:
Why is it important to differentiate between plugins and non-plugin
libraries in the maven coordinates?
Now that I see them aggregated in this nice table, thank you James, I think
it would be a lot cleaner if we c
> and
> > > one
> > > > > in
> > > > > > > > grails-gradle plugin.
> > > > > > > >
> > > > > > > > I'd rather see these named something like
; can't parallel process or cache those projects. This could be a huge
> > development burden. I would suggest we get through the discussion of the
> > artifact names and then address repackaging. Longer term, we can address
> > collapsing what the user uses.
> >
> >
> On gson vs json: if we introduce other json options in the future (i.e.
jackson) this could cause confusion. I'd rather we call them gson since
that's the underlying technology.
I'm fine with using gson instead of json.
Den tors 20 mars 2025 kl 14:40 skrev Mattias Reic
My 2 cents:
I think the blue and yellow theme is the better of the two. For some
reason, the blue and green theme does not work for me.
Grails is a full-stack, convention-over-configuration web framework that
emphasizes developer productivity, rapid development, and seamless
integration with Groov
this, but I guess we should change it back
> to "spring-security" instead of "security-spring" based on Gianluca's
> follow-up comments & James F's.
>
> On Fri, Mar 21, 2025 at 4:08 AM Mattias Reichel >
> wrote:
>
> > We are getting there!
My first thought was that the *Then method names sound nice as they read
very well when chaining methods.
However, I think the *Lazy method names are the best choice for Groovy.
/Mattias
Den tis 8 apr. 2025 kl 08:57 skrev Søren Berg Glasius :
> I think that option A is best, and it leans toward
+1 (binding)
Den ons 9 apr. 2025 kl 19:44 skrev Ricardo Vargas :
> +1
>
> On Wed, Apr 9, 2025 at 3:35 PM James Daugherty
> wrote:
>
> > Hi Everyone,
> >
> > As per the [DISCUSS] thread [1], I'd like to propose we merge the
> > grails-views & grails-gradle-plugin repos into the grails-core repo.
+1 (binding)
Den fre 11 apr. 2025 kl 18:37 skrev James Fredley :
> +1 (binding)
>
> James Fredley
>
> On 2025/04/11 16:32:38 James Daugherty wrote:
> > Hi Everyone,
> >
> > As per the [DISCUSS] thread [1], I'd like to propose we merge the
> > documentation from the grails-doc repository into the
With the performance improvements I have seen after the previous merges,
and specifically the Gradle optimizations that were part of these, I
believe this is the way to go.
Thanks James, for leading the way!
Den tors 17 apr. 2025 kl 18:23 skrev David Estes :
> I too am in huge favor of this. I b
+1 (binding)
Den lör 19 apr. 2025 18:33Walter Duque de Estrada
skrev:
> +1 (binding)
> Walter Duque de Estrada
>
> > On Apr 18, 2025, at 4:34 PM, James Fredley
> wrote:
> >
> > Hi Everyone,
> >
> > With the change to Apache Grails maven coordinates, we are moving
> profiles back to version 7.0.
+1 (binding)
Den lör 19 apr. 2025 16:22Søren Berg Glasius skrev:
> +1 (binding)
>
> Den lør. 19. apr. 2025 kl. 00.19 skrev James Fredley <
> jamesfred...@apache.org>:
>
> > Hi Everyone,
> >
> > With the change to Apache Grails maven coordinates, we are moving
> > grails-wrapper to version 7.0.x
+1 (binding)
Den ons 23 apr. 2025 21:00James Fredley skrev:
> Hi Everyone,
>
> As per the [DISCUSS] int the weekly meeting this morning [1], I'd like to
> propose we consolidate grails-profiles & grails-wrapper into grails-core.
>
> grails-core:grails-bom references the versions of grails-profil
I think we should keep using repo.grails.org for now (below the other
repos, in the repositories block), and await JFrogs answer, if we can keep
using it.
/Mattias
Den lör 3 maj 2025 kl 10:42 skrev Gianluca Sartori :
> Hi James & James,
>
> I agree we should move to repo.gradle.org/gradle/libs-r
herty
:
> @Mattias, what are your thoughts about creating a new repository on
> repo.grails.org to isolate legacy artifacts?
>
> On Sat, May 3, 2025 at 7:52 AM Mattias Reichel
> wrote:
>
> > I think we should keep using repo.grails.org for now (below the other
> > rep
+1 (binding)
/ Mattias
Den fre 18 apr. 2025 17:25James Fredley skrev:
> +1 (binding)
>
> James Fredley
>
> On 2025/04/18 15:20:04 James Daugherty wrote:
> > Hi Everyone,
> >
> > As per the [DISCUSS] thread [1], I'd like to propose we form a mono repo
> > for the "grails-core" libraries by mergi
Yes, we should update! +1
Den tors 8 maj 2025 kl 09:22 skrev Søren Berg Glasius :
> I think this is a good, and responsible idea, especially with all the tests
> passing.
>
> Den tors. 8. maj 2025 kl. 00.06 skrev James Fredley <
> jamesfred...@apache.org
> >:
>
> > Given the current timeline for
forge-*"
> >> plus "grails forge" would be mapped from the wrapper to run grails-forge
> >> CLI. Any others would run grails-shell CLI.
> >>
> >> This is close enough to having two commands "grails" and "grailsforge&quo
ere are no direct dependencies on each other, and
> the Forge can be developed and bugs fixed quickly. That's how Spring
> Initializr has been implemented since the beginning.
>
>
> Mattias Reichel 于2025年3月3日周一 17:40写道：
>
> > Thanks for your input, Michael - this
Damn, we're moving fast! 🚀 😆
On 2025/03/03 14:03:48 James Daugherty wrote:
> Hi Everyone,
>
> I started to publish the M2 this morning (as we agreed last week) and
> realized I kicked off the wrong release task instead of the pre-release
> task. I've opened https://github.com/grails/grails-core
As many of you know, the old "Grails Shell CLI" (the grails executable
distributed with SDKMAN up to Grails 5, also runnable via ./grailsw) has
been restored in Grails 7. Meanwhile, the "Grails Forge CLI" (introduced
and distributed via SDKMAN for Grails 6, and powering start.grails.org)
remains th
In my Grails applications, I remove the grails-logging library and
explicitly annotate classes with @Slf4j where logging is needed.
My question is: Is it worth maintaining a library whose sole purpose, as
far as I know, is to automatically add @Slf4j to all Grails artifact
classes?
is no need
> for them.
>
> Gianluca Sartori
>
>
> On Wed, 12 Mar 2025 at 18:06, Mattias Reichel
> wrote:
>
> > In my Grails applications, I remove the grails-logging library and
> > explicitly annotate classes with @Slf4j where logging is needed.
> >
> &
+1 to proposed users, commits and notifications mailing lists
On 2025/02/21 06:14:04 Paul King wrote:
> Hi folks,
>
> Currently Grails has private and dev mailing lists created. Folks
> interested in the development of Grails should subscribe to the dev
> list. Folks on the PPMC (podling project
I can be a moderator on the users list 🙋
On 2025/02/24 23:58:20 Paul King wrote:
> I created (still pending with a 12-24 hr delay) the lists with the
> default list behavior which lets subscribers post but others are
> moderated.
>
> It would be good to have a few PPMC folks to help moderate the
>
> Does someone want to create an issue to make the old lists read-only
> once the new lists are up and running? At least for users.
>
> https://github.com/grails/grails-core/issues/14040
Den ons 26 feb. 2025 kl 21:56 skrev Paul King :
> Added.
>
> On Thu, Feb 27,
Works for me!
Den fre 4 apr. 2025 kl 10:33 skrev Gianluca Sartori :
> That would be fine for me in CEST
>
> Gianluca Sartori
>
> On Fri, 4 Apr 2025 at 01:29, Walter Duque de Estrada
> wrote:
>
> > That works for me in CST
> >
> > Walter
> >
> > > On Apr 3, 2025, at 1:40 PM, James Fredley
> > wr
+1 (binding)
Den tors 3 apr. 2025 kl 21:35 skrev James Daugherty
:
> Hi Everyone,
>
> As per the [DISCUSS] thread [1], I'd like to propose we merge the
> grails-cache repo into the grails-core repo.
>
> The vote is open for the next 72 hours and passes if all binding votes are
> cast in favor.
>
I'm sorry Andrew, you are absolutely right!
I may have misunderstood what feedback is wanted.
/Mattias
Den fre 21 mars 2025 kl 14:16 skrev Andrew Garcia
:
> Another option is to just let the designer explore and put forward ideas of
> color/designs that are both modern and differentiated enoug
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
LGTM!
Thank you Paul.
Den tis 13 maj 2025 kl 13:40 skrev James Daugherty
:
> Seems like the weekly meetings are ancillary since we summarize them on the
> mailing list. I'd personally leave it off.
>
> Otherwise, It looks fine to me and the point about communication is
> probably relevant to inc
I think we should keep this as a side branch for now.
If I understand correctly, we will still have issues with reproducibility,
so I don't see the value in merging it at the moment.
Merging it will make Groovy a moving target that might create problems that
are difficult to diagnose/understand whe
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
skrev:
> @Mattias what are your thoughts here? I was t
+1 (binding)
Den tis 24 juni 2025 kl 20:26 skrev James Fredley :
> Thank you.
>
> +1 (binding)
>
> James Fredley
>
> On 2025/06/24 18:14:40 James Daugherty wrote:
> > Hi Everyone,
> >
> > As per the discussion [1], we received feedback [2] during our last
> > grails-core release about how we need
These are the dependencies between the Grails Forge and Grails Core
projects:
grails-forge-core
└── org.apache.grails.profiles:base (grails-core) (build dependency for
copying grails-wrapper files from base profile to generated applications)
grails-forge-cli
└── grails-forge-core
grails-cli
├──
+1 (binding)
Den lör 21 juni 2025 kl 19:18 skrev Walter Duque de Estrada
:
> +1
>
> Walter Duque de Estrada
>
> > On Jun 20, 2025, at 10:56 AM, James Fredley
> wrote:
> >
> > Hi Everyone,
> >
> > With the https://grails.apache.org/ site published, I believe we are
> now ready to redirect https:/
By all means, let's put it in a nested project.
Den mån 23 juni 2025 kl 22:27 skrev James Fredley :
> After a few conversations with James Daugherty, I think bringing all 6
> grails-forge subprojects over to grails-core is the best approach for the
> following reasons:
>
> - We are limited on tim
> Basically, by merging partially, it makes our life easier, and their life
harder. By merging both, we keep it simple for everyone.
This sentence, puzzles me a bit.
I think start.grails.org infrastructure code can be kept separate and we
merge only the CLI projects needed for a release.
/Mattia
+1 (binding)
Den ons 4 juni 2025 kl 15:41 skrev Andrew Garcia
:
> +1 (non-binding)
>
> On Wed, Jun 4, 2025 at 9:39 AM James Fredley
> wrote:
>
> > +1 (binding)
> >
> > Thank you for working into the early hours of the morning to get this
> > restaged.
> >
> > James Fredley
> >
> > On 2025/06/04
+1 (binding)
Den tors 12 juni 2025 kl 17:21 skrev David Estes :
> +1 (binding)
> Sent from my iPhone
>
> > On Jun 12, 2025, at 9:54 AM, James Fredley
> wrote:
> >
> > +1 (binding)
> >
> >> On 2025/06/12 02:42:12 James Daugherty wrote:
> >> Hi Everyone,
> >>
> >> I am happy to start the VOTE thr
Yes!
That would be terrific, thank you James!
Den sön 6 juli 2025 23:54James Daugherty
skrev:
> Hi Everyone,
>
> We have recently merged some significant, impactful changes. I've created
> a 7.0.0-M5 milestone in the issue tracker to track everything that should
> now be resolved:
>
> https://g
+1 (binding)
Den ons 9 juli 2025 kl 17:37 skrev James Daugherty :
> Hi Everyone,
>
> I am happy to start the VOTE thread for an Apache Grails (incubating)
> release of version 7.0.0-M5!
>
> Pre-release discussion thread is here:
> https://lists.apache.org/thread/34qhoyfwxyhkhl671wbgpvrrny8gmpfc
>
+1 (binding)
Den tors 3 juli 2025 kl 14:58 skrev Walter Duque de Estrada
:
> +1 Binding
> Walter
>
> > On Jul 2, 2025, at 7:09 PM, David Estes wrote:
> >
> > +1 (binding)
> > Sent from my iPhone
> >
> >> On Jul 2, 2025, at 2:42 PM, Søren Berg Glasius
> wrote:
> >>
> >> +1 (binding)
> >>
> >>>
Scott, I know this is disappointing, with all the work you have put in.
However, I think this ship has sailed, but there is always the next one.
Some comments on you points below:
* Rapid fix is feasible
* I can resolve the outstanding SiteMesh 3 issues in two weeks when my
schedule frees up.
T
Yes, I think it's the right thing to do at this point.
/Mattias
Den ons 2 juli 2025 kl 16:23 skrev James Fredley :
> I believe this is the quickest and likely best way to ensure GSP in Grails
> 7 works the way it did in Grails 5 and 6.
>
> It addresses the long term open issues with Sitemesh 3 u
+1 (binding)
Den mån 30 juni 2025 kl 20:28 skrev James Fredley :
> +1 (binding)
>
> James Fredley
>
> On 2025/06/30 17:09:33 James Daugherty wrote:
> > Hi Everyone,
> >
> > As per discussion [1], I am proposing we split the Grails Publishing
> gradle
> > plugin into its own repo with its own rele
It seems the Grails Publish Plugin has one dependency on another module,
`grails-gradle-model`, and its class `GrailsNameUtils`.
However, this is only used to make the first character of a string
uppercase, so that can easily be replaced.
I think this split makes sense, if it means we can leverage
+1 (binding)
Den ons 16 juli 2025 kl 00:53 skrev James Fredley :
> Hi Everyone,
>
> The asf branch is used within all Apache Grails projects and is the
> currently maintained branch.
>
> https://github.com/apache/grails-github-actions
>
> The vote is to change the default branch from main to asf.
+1 (binding)
Den tors 24 juli 2025 kl 17:49 skrev James Daugherty
:
> Hi Everyone,
>
> I am happy to start the VOTE thread for Apache Grails (incubating)
> Plugin - Redis 5.0.0-M5!
>
> At a high level, this plugin is being updated to support the
> recent Grails 7.0.0-M5 release. Further details o
+1 (binding)
Den tors 24 juli 2025 kl 17:54 skrev James Daugherty
:
> Hi Everyone,
>
> I am happy to start the VOTE thread for Apache Grails (incubating)
> Plugin - Spring Security 7.0.0-M5
>
> At a high level, this plugin is being updated to support the
> recent Grails 7.0.0-M5 release. Further
+1 (binding)
Den fre 25 juli 2025 17:33James Daugherty
skrev:
> Hi Everyone,
>
> I am happy to start the VOTE thread for Apache Grails (incubating)
> Plugin - Quartz 4.0.0-M3
>
> At a high level, this plugin is being updated to support the
> recent Grails 7.0.0-M5 release. Further details of thi
55 matches
Mail list logo
