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 also enables your application to use hibernate5 (and that plugin depends on the other library). Which one would org.apache.grails:grails-data-hibernate5 refer to?
There will likely be numerous conflicts if we strip the `plugin` from the package and the artifact - for example async, event, gsp, and some of the gorm-async stuff will overlap. The plugin is typically what we expect end users to include in their application to enable functionality. The plugin is further subdivided into libraries to assist in fast compilation / development. Sometimes people even swap the libraries based on the implementation they prefer (async rxjava2 vs rxjava3, etc). -James On Wed, Mar 19, 2025 at 12:10 PM Mattias Reichel <mattias.reic...@gmail.com> wrote: > 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 could strip the plugin part in both group > and artifactId for many or all of these: > > org.apache.grails:grails-codecs > org.apache.grails:grails-controllers > org.apache.grails:grails-databinding > org.apache.grails:grails-datasource > org.apache.grails:grails-domain-class > org.apache.grails:grails-i18n > org.apache.grails:grails-interceptors > org.apache.grails:grails-mimetypes > org.apache.grails:grails-rest-responder > org.apache.grails:grails-services > org.apache.grails:grails-url-mappings > > org.apache.grails:grails-async > org.apache.grails:grails-converters > org.apache.grails:grails-events > org.apache.grails:grails-sitemesh3 > org.apache.grails:grails-fields > org.apache.grails:grails-views-gsp > org.apache.grails:grails-views-gson > org.apache.grails:grails-views-markup > org.apache.grails:grails-scaffolding > > org.apache.grails:grails-data-hibernate5 > org.apache.grails:grails-data-hibernate6 > org.apache.grails:grails-data-migration-hibernate5 > org.apache.grails:grails-data-migration-hibernate6 > org.apache.grails:grails-data-mongodb > > org.apache.grails:grails-cache > org.apache.grails:grails-geb > org.apache.grails:grails-spring-security-acl > org.apache.grails:grails-spring-security-cas > org.apache.grails:grails-spring-security-core > org.apache.grails:grails-spring-security-ldap > org.apache.grails:grails-spring-security-oauth2 > org.apache.grails:grails-spring-security-rest > org.apache.grails:grails-spring-security-rest-data > org.apache.grails:grails-spring-security-rest-grails-cache > org.apache.grails:grails-spring-security-rest-memcached > org.apache.grails:grails-spring-security-rest-redis > org.apache.grails:grails-spring-security-ui > > org.apache.grails:grails-redis > org.apache.grails:grails-quartz > > Regards > Mattias > > Den ons 19 mars 2025 kl 16:25 skrev James Daugherty > <jdaughe...@jdresources.net.invalid>: > > > 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 have one of these > > prefixes and I think a prefix should be added to the artifactid. > > 1. Did my table miss adding prefixes? I think I added all of the ones I > > was aware of ... > > 2. I agree with you on the location - starting allows them to be used as > a > > prefix and allows discoverability via maven. > > > > >grails-gradle-plugins is slightly confusing when > grails-gradle-plugin-*'s > > exist. Maybe something like grails-gradle-plugin-core/base/main/common, > > same for grails-gradle-view-plugins > > grails-gradle-plugins isn't a gradle plugin. It's the grouping for all > > gradle plugins under that given repo. This is what we often add to the > > classpath in buildScript to import all of the known plugins > > > > > grails-view-plugin- and grails-security-plugin-, should plugin come > > before view and security? I agree with grails-gradle-plugin, but am > unsure > > on these two. > > I'm fine changing that, but shouldn't gorm & view be included in this? > > grails-plugin-gorm, grails-plugin-security, grails-plugin-view, > > grails-plugin-gorm - how do these sound? > > > > > The 2 artifactids that start with views- should start with > grails-views- > > Can you identify these artifacts? Are you talking about the gradle > plugins > > (we renamed these already) or something else? > > > > > I think org.apache.grails.forge:grails-cli should be > > org.apache.grails.forge:grails-forge-cli. This may be a good time to > > rename grails-shell to grails-shell-cli also. > > I agree with these. > > > > > The long artifactids, like, org.grails.grails-gsp.gradle.plugin ... are > > the way Gradle Plugins can be published to a non-Gradle Plugin Portal > > Are you sure about this statement? I noticed the views plugins (markup / > > json) do not have this and they are used in projects without issue - > that's > > why I proposed the change. > > > > > Can we standardize gorm-, grails-datastore-gorm-, grails-gorm-plugin- > and > > grails-datastore- around grails-data- and grails-plugin-data- > > So grails-plugin-gorm becomes grails-plugin-data? That's reasonable. > For > > the datastore & gorm, I think we need to work through each of these since > > for each gorm implementation there is often a base implementation and > then > > a plugin that exposes that implementation and then there are the base > gorm > > libraries that are considered part of the original data-mapping. Can you > > enumerate what should be renamed to what? > > > > Regards, > > James > > > > > > On Wed, Mar 19, 2025 at 11:11 AM James Fredley <jamesfred...@apache.org> > > wrote: > > > > > 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-plugin- and grails-security-plugin-. > > > > > > On 2025/03/19 13:02:18 Søren Berg Glasius wrote: > > > > 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.apache.grails.plugins > > > > grails-plugin-scaffolding grails-views > > > > org.grails.plugins views-json org.apache.grails.plugins > > > > grails-view-plugin-gson grails-views > > > > org.grails views-core org.apache.grails views-core grails-views > > > > org.grails views-json-testing-support org.apache.grails.testing > > > > views-json-testing-support grails-views > > > > org.grails views-markup org.apache.grails.plugins > > > grails-view-plugin-markup > > > > grails-views > > > > IMO we should decide where the word *plugin* is placed in the name. > > > > Personally I'd prefer *grails-x-plugin*, and *grails-view-x-plugin* > (so > > > > *grails-fields-plugin* and *grails-view-gsp-plugin* for examples and > > > > perhaps *grails-view-core*) for consistency. > > > > > > > > Just my 0.02€ worth. > > > > > > > > > > > > Den ons. 19. mar. 2025 kl. 13.46 skrev James Daugherty > > > > <jdaughe...@jdresources.net.invalid>: > > > > > > > > > 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 > > > upgrading > > > > > to the ASF packages, I am proposing we create a 'RENAME.md' > markdown > > > file > > > > > in the grails-core repository. We can then later include this file > > on > > > the > > > > > website, grails docs, etc. > > > > > > > > > > My attempt at mapping the new group ids and artifacts ids are here: > > > > > > > > > > > > > > > > https://github.com/apache/grails-core/blob/9ac56cac136f5228d783bda5671a49d433901ba5/RENAME.md > > > > > > > > > > > > > > > The PR to add this file to grails-core is here: > > > > > https://github.com/apache/grails-core/pull/14074/files > > > > > > > > > > Can people either comment on the PR or discuss here for the > proposed > > > > > renames? > > > > > > > > > > Regards, > > > > > James > > > > > > > > > > > > > > > > > -- > > > > > > > > Med venlig hilsen, > > > > Søren Berg Glasius > > > > > > > > Hedevej 1, Gl. Rye, 8680 Ry > > > > Mobile: +45 40 44 91 88 > > > > --- Press ESC once to quit - twice to save the changes. > > > > > > > > > >
