artifact rename proposal

[jdaugherty]

High level feedback on the proposal:

• org.apache.grails will be used for any plugin traditionally included by an end-user in their grails or spring app.
• group ids for implementation details or dependencies of a grails plugin will use a subpackage.
  • i.e. the codecs plugin would have a group of org.apache.grails and the codecs-api that the plugin includes would have a group of org.apache.grails.codecs
• testing artifacts for end-user grails applications will have a special rule to be prefixed with grails-testing- to ensure people are not including them in a regular application.
• gradle plugins will be consolidated under the repo https://github.com/apache/grails-gradle-plugin. There will be one artifact published that can be included in a build script / source to import all of the gradle plugins. That artifact will be: org.apache.grails:grails-gradle-plugins
• because profiles are not an artifact distributed to an application, they will not be prefixed with a "grails-"
• artifacts should be prefixed with grails- (unless a profile)
• json => gson to reflect the view technology and to avoid confusion with other json implementations
• views is dropped from the artifact id to be consistent with view technologies (gsp, gson, markup)
• several artifacts are renamed for clarity, for example grails-console -> grails-gradle-console
• we have appended '-cli' where a cli is being provided
• for plural vs singular on package names / artifacts / groups we have decided on plural usage, while single in class usage. This matches the existing code base for projects like events

[jamesfredley]

Reviewed: https://github.com/jdaugherty/grails-core/blob/3b4da92e339b7b688011e4a8ffc3c2aaea723680/RENAME.md?plain=1 iteration

I am still a little concerned with the artifacts being security-spring and the project name being spring-security. Matching the upstream project seems like the best idea https://github.com/spring-projects/spring-security.

[rainboyan]

I don't think it's a good idea to use different groupIds in the same repository.

[jdaugherty]

Because of the circular dependencies, I don't think we can realistically adhere to keeping the same package for an entire repo. We have intentionally brought code together in 7 because we found so much of it wasn't being tested. We may even be forced to bring more repositories together because of the requirements of the ASF release process.

[matrei]

I don't think it's a good idea to use different groupIds in the same repository.

@rainboyan Why don't you think it's a good idea? (We will use this practice extensively in the Grails Core repository.)

[rainboyan]

I haven't seen this practice in other open source projects before. I don't think this solves the circular dependency problem.

[jdaugherty]

I'm saying that the circular dependency problem is slowly being solved by collapsing the repos. Meaning, there will be several gradle projects in the same repo going forward. For example, grails-core.

[jdaugherty]

Spring uses an artifact prefixes to distinguish the purpose, but since we're removing Plugin from the name we agreed on using the group id instead of using prefixes.

[rainboyan]

Spring uses an artifact prefixes to distinguish the purpose, but since we're removing Plugin from the name we agreed on using the group id instead of using prefixes.

Until a better solution comes out, I still recommend not changing.

[rainboyan]

How about changing repository to: grails-security,
and using group org.apache.grails.security?
-- org.apache.grails.security.spring (package name)
---- grails-security-spring-acl
---- grails-security-spring-cas
-- org.apache.grails.security.shiro (package name)
---- grails-security-shiro

[jdaugherty]

The agreement was to remove Plugin / starter conventions and replace with a single root group id "org.apache.grails"

[rainboyan]

Maybe I missed the previous discussion, but is this convention a well-known rule, or is it just a common understanding among Grails developers? This makes it difficult for me to understand.

[rainboyan]

Maybe I missed the previous discussion, but is this convention a well-known rule, or is it just a common understanding among Grails developers? This makes it difficult for me to understand.

[jdaugherty]

In the discussion for this PR on the mailing list, we made this proposal so we could move forward with removing plugin from the names.

[rainboyan]

If I must have a choice between using plugin suffix and using the root groupId org.apache.grails to distinguish between plugins and libraries, I will choose the first one. In Grace, I have always used plugin as the archiveClassifier of the plugin jars.
For example, fields-6.0-plugin.jar, cache-6.0-plugin.jar, So, it's easy for us to know that these are plugins.

[matrei]

This is what a default generated web-app (from the current state of grails-forge-cli) dependencies blocks will look like with this proposal. I think it looks pretty good. Note the outlier org.apache.grails.web:grails-web-boot:

buildscript {
    dependencies {
        classpath "com.bertramlabs.plugins:asset-pipeline-gradle"
        classpath platform("org.apache.grails:grails-bom:$grailsVersion")
        classpath "org.apache.grails:grails-gradle-plugins"
        classpath "org.apache.grails:grails-data-hibernate5"
    }
}

apply plugin: "asset-pipeline"
apply plugin: "org.apache.grails.gradle.grails-web"
apply plugin: "org.apache.grails.gradle.grails-gsp"

dependencies {
    profile "org.apache.grails.profiles:web"
    developmentOnly "org.webjars.npm:bootstrap"
    developmentOnly "org.webjars.npm:bootstrap-icons"
    developmentOnly "org.webjars.npm:jquery"
    implementation platform("org.apache.grails:grails-bom:$grailsVersion")
    implementation "org.apache.grails:grails-core"
    implementation "org.apache.grails:grails-logging"
    implementation "org.apache.grails:grails-databinding"
    implementation "org.apache.grails:grails-i18n"
    implementation "org.apache.grails:grails-interceptors"
    implementation "org.apache.grails:grails-rest-transforms"
    implementation "org.apache.grails:grails-services"
    implementation "org.apache.grails:grails-url-mappings"
    implementation "org.apache.grails.web:grails-web-boot"
    implementation "org.apache.grails:grails-gsp"
    implementation "org.apache.grails:grails-data-hibernate5"
    implementation "org.apache.grails:grails-scaffolding"
    implementation "org.springframework.boot:spring-boot-autoconfigure"
    implementation "org.springframework.boot:spring-boot-starter"
    implementation "org.springframework.boot:spring-boot-starter-actuator"
    implementation "org.springframework.boot:spring-boot-starter-logging"
    implementation "org.springframework.boot:spring-boot-starter-tomcat"
    implementation "org.springframework.boot:spring-boot-starter-validation"
    console "org.apache.grails:grails-console"
    runtimeOnly "com.bertramlabs.plugins:asset-pipeline-grails"
    runtimeOnly "com.h2database:h2"
    runtimeOnly "com.zaxxer:HikariCP"
    runtimeOnly "org.fusesource.jansi:jansi"
    integrationTestImplementation testFixtures("org.apache.grails:grails-geb")
    testImplementation "org.apache.grails:grails-testing-support-gorm"
    testImplementation "org.apache.grails:grails-testing-support-web"
    testImplementation "org.spockframework:spock-core"
}