James,
Thank you for building a full table based on the thoughts captured in
https://github.com/apache/grails-core/issues/14006 back in Feb. This looks
really good.
My initial thoughts and opinions on the table:
https://github.com/jdaugherty/grails-core/blob/renameProposal/RENAME.md
org.apa
Some follow-up notes:
> The artifactid containing grails-, grails-plugin-, grails-profile- or
grails-gradle-plugin- is important so that the jar filename is clear and
descriptive when pulled from maven central and you are viewing them in a
fat jar/war or directory. There are a few that do not ha
I think the future of Grails will be like this. Plugins will no longer
exist! At least most of them will not be needed. Therefore, artifact names
will not include the *plugin* prefix or suffix.
I agree with the naming proposed by Mattias, but I think the groupId should
include some specific categor
Posting here on behalf of Martyn Duffy:
Hey everyone, I wanted to share an initial take on a new Grails landing page.
Would love your feedback on how to best capture the essence of Grails:
What do we want new visitors to immediately understand about the framework?
What do you think Grails’ uniq
I would love to see Grails 7 getting in touch with its origins to pave
its legacy.
The original green should get back, with the complementary orange links,
supporting the new rounded logo.
On the selling proposition, I would give the following priorities:
*1. Enterprise grade*
- 20 years of e
Mattias made a good point in his open PR: there are other security
frameworks such as https://shiro.apache.org/. This convinced me to keep
the 'spring' in the name to be clear.
Looking at Mattias' revision and comparing it to James Fredley's, I think I
agree with everything James Fredley has exce
James Fredley: I am good with your proposal.
Søren, Mattias, Michael, and Gianluca - does James’s updated version work
for you all?
I am ok removing grails profile from the artifact id too.
If Michael is willing to help us consolidate, it would be wonderful.
Otherwise, I would suggest we leave c
If the future of project generation is Grails Forge and it's CLI, and also
no one will like to use Shell CLI to create new projects, I think we can
make the profile optional for the Shell CLI. Shell CLI will allow to
execute Application Commands without profiles, so we don't have to maintain
these
https://github.com/apache/grails-core/pull/14077/files
replaced 'mongo-gson-templates' with 'grails-data-mongodb-gson-templates' to
match it up with the project. It also looks like it was changed from json to
gson before I added the prefix.
Are you proposing always applying the Grails Gradle pl
That is a great point about the profile not being included in the final
distribution.
consolidation of the profiles would be great. Do you have any time to work on
this task?
On 2025/03/20 00:48:09 Michael Yan wrote:
> If using 'org.apache.grails.profiles' as groupId, why do we need to add
I agree with Gianluca,
I'd love to see Grails back in green too!
I'd also add to the selling points:
- Build full-stack applications fast and easily.
Ricardo V.
On Wed, Mar 19, 2025 at 9:48 PM Gianluca Sartori
wrote:
> I would love to see Grails 7 getting in touch with its origins to pav
Here is a further updated table with the views Gradle plugins consolidated into
grails-gradle-plugin, which is renamed back to its original name. This update
also moves grails-test to the correct groupid.
https://github.com/apache/grails-core/blob/jamesfredley/renameProposal/RENAME.md
PR: h
If using 'org.apache.grails.profiles' as groupId, why do we need to add
the prefix grails-profile-? The profile artifact will not be packaged in
the final distributions.
Also I think we don't need so many profiles, some of theme can be merged,
included base. Maybe we also can make angular, react,
Makes sense on the gson-templates update.
Concerning the gradle plugins, I think there's some confusion here. The
"grouping" artifact isn't a gradle plugin. It only adds the gradle plugins
to the classpath so it would not be used in a plugin { } block. I am
speaking about these lines:
https://
Currently, I am a little worried about such a drastic change. Renaming the
package name seems easy, but it will also bring a lot of trouble, which is not
wise to change in 7.x.
Before that, we still have a lot of work to do, such as defining the
responsibilities and scope of each module, sorting
Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 16 April 2025.
The report for your podling will form a part of the I
Awesome!
-Lari
On 2025/03/13 18:13:57 James Fredley wrote:
> A JIRA ticket has been submitted with ASF infrastructure to migrate the
> following repositories to https://github.com/apache/.
>
> https://github.com/grails/grails-core
> https://github.com/grails/grails-gradle-plugin
> https://git
Hi,
I agree on most, but wonder why there is inconsistency on some of the
plugin naming:
org.grails.plugins fields org.apache.grails.plugins grails-plugin-fields
grails-views
org.grails.plugins gsp org.apache.grails.plugins grails-view-plugin-gsp
grails-views
org.grails.plugins scaffolding org.ap
Forgot, there was one more too:
grails-security-plugin (note the drop of "spring").
On Wed, Mar 19, 2025 at 9:34 AM James Daugherty
wrote:
> If we treat the keyword as a prefix, it is easier to find them on maven
> central. These were the prefixes being suggested:
>
> grails-view-plugin (gsp
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
How do we distinguish between the implementation and the exposure of that
implementation? Take for example hibernate5 - there's an implementation of
grails datastore that implements hibernate (this library imports the
hibernate libraries, implements criterias, etc), and then there's a plugin
that
- What do we want new visitors to immediately understand about the framework?
Apache Grail is a convention over configuration, Don’t Repeat Yourself (DRY),
full stack framework similar to Rails and Django, built on the enterprise
foundation of Spring Boot and Hibernate with a nearly two decade h
I almost forgot: it also may conflict with upstream names too. The jar
will take the name of the artifact id, and in the case of the sitemesh 3
plugin, if the package was called "sitemesh3" then the jar will match the
upstream library's jar too. I believe there was a desire to prefix the
artifact
Hi Everyone,
Per previous meetings, we agreed to rename the maven coordinates as part of
transitioning to the ASF. During this renaming, we also set out several
requirements for being consistent with our group ids and artifact ids.
Since these renames are going to be referenced heavily by anyone
I put a number of related details in my longer post. In terms of location of
the word `plugin` in the artifactid, I prefer towards the beginning vs at the
end. This makes grouping and search a bit simpler. I we go this direction, we
need to make decisions on grails-view-plugin-, grails-gradle
25 matches
Mail list logo
