> Did you mean to say artifact ids instead of groupIds?
Yes, sorry for the confusion, I meant artifactIds.
Den fre 21 mars 2025 kl 15:55 skrev James Daugherty
:
> 1. Did you mean to say artifact ids instead of groupIds?
> 2. We should decide on noun vs plural forms. I'm personally a fan of the
Does this proposal address all of the issues then?
https://github.com/apache/grails-core/pull/14080
On Thu, Mar 20, 2025 at 9:44 AM Mattias Reichel
wrote:
> > 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
Long term, I think we do need to combine profiles and forge. I think both
James F & I are supportive of your proposal. This thread is about the artifact
renames so we can start publishing to the ASF though. Can we take this to the
ticket or another thread instead?
On 2025/03/20 01:39:03 Mic
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 / markup / gson)
grails-plugin
grails-profile
grails-gradle-plugin
grails-gorm-plugin
We could simplify these to just grails-plugin and not distinguis
I reviewed the
https://github.com/jdaugherty/grails-core/blob/3b4da92e339b7b688011e4a8ffc3c2aaea723680/RENAME.md?plain=1
iteration and put my approval on the PR.
I am still a little concerned with the artifacts being security-spring and the
project name being spring-security. Matching the upst
About the repository names, are there reasons not to shorten the following?
grails-data-mapping -> grails-data
grails-spring-security -> grails-security
grails-gradle-plugin -> grails-gradle
Gianluca
On Thu, 20 Mar 2025 at 15:56, James Daugherty
wrote:
> Does this proposal address all of the
Okay sounds good
Gianluca
On Thu, 20 Mar 2025 at 17:52, James Daugherty
wrote:
> I don't think we should rename any repositories until builds are fully
> working. It will delay the 7 release process otherwise. The goal of this
> discussion is specific to the groupid / artifactid.
>
> On Thu,
I tried to update the PR description to summarize some of the highlights of
this thread. If I missed anything, please speak up.
I also realized the grails-console had a subpackage, so I removed that
subpackage for consistency.
https://github.com/apache/grails-core/pull/14080
-James
On Thu, Mar
as for grails-spring-security, I think it makes sense to keep it, because
there is also shiro security, and while it is not released under Apache, it
is still a thing.
Den tors. 20. mar. 2025 kl. 16.56 skrev Gianluca Sartori <
g.sart...@gmail.com>:
> About the repository names, are there reasons
Yes, I am just talking about the repository name, not the groupId or
artifactId.
The repository name can be any name available in our Git namespace, it will
not conflict or influence any other repository name on any other GitHub
namespace.
Gianluca
On Thu, 20 Mar 2025 at 17:06, Søren Berg Glasius
Actually, how about this proposal:
Why don't we make anything that is a plugin have a root group id of
"org.apache.grails", and anything that's supportive have a nested group
name based on the type?
On Thu, Mar 20, 2025 at 8:42 AM James Daugherty
wrote:
> Here are the differences between James
Mattias' suggestion is the most convincing naming scheme to me.
Keeping the right-to-left grouping strategy I would probably give
precedence to the hibernate implementation.
Even though there are reasons to keep the "spring" name in the
"spring-security" plugins (search the web) I would rather hav
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
I'm sorry, I've missed this message! I'm fine with that.
Following up with James F. concerns about "grails-security-spring" VS
"grails-spring-security" though, I agree it is probably better to keep
"spring-security" to avoid confusion. In case of other security libraries
it could just be eg. "grai
IMO, just changing org.grails to org.apache.grails is the fastest way to
release M4.
On 2025/03/21 17:52:18 James Daugherty wrote:
> I'll start a vote thread in 3 hours if there isn't any more feedback so we
> can get snapshot builds working next week.
>
> It's rather critical we get this done s
I updated the PR.
On Fri, Mar 21, 2025 at 1:02 PM Mattias Reichel
wrote:
> Thank you James!
> My question was more regarding why two of them are collapsed:
> - databinding
> - datastore
> vs non-collapsed:
> - data-mapping
>
> Den fre 21 mars 2025 kl 17:30 skrev James Daugherty
> :
>
> > Data bi
I'll start a vote thread in 3 hours if there isn't any more feedback so we
can get snapshot builds working next week.
It's rather critical we get this done since we still have major grails 7
issues remaining to address before a RC can be made. If we don't get
snapshot publishing completed in Marc
This has had the highest participation of any Grails conversation over the last
~9 months, which is exciting to see.
The goal of this step is to move to Apache groupids, which are required to
setup snapshot publishing at ASF, which will allow us to resume development
with the 18 migrated git re
Thank you James!
My question was more regarding why two of them are collapsed:
- databinding
- datastore
vs non-collapsed:
- data-mapping
Den fre 21 mars 2025 kl 17:30 skrev James Daugherty
:
> Data binding & data mapping are definitely related. Binding is
> transforming one source format to ano
Data binding & data mapping are definitely related. Binding is
transforming one source format to another. I.e. form url encoding being
parsed and populating properties on a class file. It only deals with
copying data from a source to a target.
I would still view them separately since data mappi
1. Did you mean to say artifact ids instead of groupIds?
2. We should decide on noun vs plural forms. I'm personally a fan of the
noun approach. What are other people's thoughts?
3. I named it model because all that library does is expose the classpath.
I could see it being used for other purpose
Excuse a non-native english speaker, should these be treated the same or
differently?
databinding
datamapping
datastore
Den fre 21 mars 2025 kl 16:38 skrev James Daugherty
:
> I've updated the pull request for the following:
>
> artifactId: grails-gradle-console -> grails-console
> artifactId: gr
I've updated the pull request for the following:
artifactId: grails-gradle-console -> grails-console
artifactId: grails-gradle-model changed package from model -> gradle
artifactId: grails-security-spring -> grails-spring-security
artifactId: grails-rest-responder -> grails-rest-transforms
groupId
Thank you. I'd rather we hyphenate all words in the artifact id. It'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, Mar
Okay, my proposal was based on the meaning of “security” as a group rather
than referencing to a specific library (remaining open to other security
libraries) but I can see your concerns.
It may be better not to reverse the spring security name.
It could be “grails-security-spring-security” but I
@Gianluca, were you ok with the latest draft?
https://github.com/apache/grails-core/pull/14080
On Thu, Mar 20, 2025 at 12:56 PM Gianluca Sartori
wrote:
> Okay sounds good
>
> Gianluca
>
>
> On Thu, 20 Mar 2025 at 17:52, James Daugherty
> wrote:
>
> > I don't think we should rename any repositor
I don't think we should rename any repositories until builds are fully
working. It will delay the 7 release process otherwise. The goal of this
discussion is specific to the groupid / artifactid.
On Thu, Mar 20, 2025 at 12:46 PM Gianluca Sartori
wrote:
> Yes, I am just talking about the reposi
I updated the PR to include Robert's feedback.
On Thu, Mar 20, 2025 at 11:07 AM Robert Oschwald
wrote:
> Just my 2c:
>
> grails-data-hibernate[5|6]-migration I would name
> grails-data-hibernate[5|6]-dbmigration
>
>
>
> > Am 20.03.2025 um 15:54 schrieb James Daugherty <
> jdaughe...@jdresources.
Just my 2c:
grails-data-hibernate[5|6]-migration I would name
grails-data-hibernate[5|6]-dbmigration
> Am 20.03.2025 um 15:54 schrieb James Daugherty
> :
>
> Does this proposal address all of the issues then?
>
> https://github.com/apache/grails-core/pull/14080
> 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 Reichel <
mattias.reic...@gmai
> Spring calls these starters, grails calls them plugins.
I'm not sure this analogy is 100% correct. Aren't Spring Starters just
dependency aggregators, not bringing any code of their own.
Maybe Spring AutoConfigurations are more analogous to Grails Plugins?
Anyways, I think the concept of Plugins
Here are the differences between James Fredley's proposal and Mattias's (I
couldn't attach an image unfortunately):
grails-codecs-core
grails-databinding-core
grails-gradle-plugins
grails-gsp
spring-security-rest-testapp
grails-views-js
I have made another iteration based on James' latest updates and some great
observations and suggestions from this thread.
- Make sections for "NORMAL", GRADLE, PROFILES and FORGE
- Sort by artifactId (I found some collisions, added '-core' to those)
- Rename some artifactIds
- Remove '-views' f
On Thu, 20 Mar 2025 at 00:24, James Daugherty
wrote:
> 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.
>
True. I still have this feeling though that everything sp
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
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
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
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
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,
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
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
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
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
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
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
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
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 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
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
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
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
52 matches
Mail list logo
