For end users, backward compatibility is very important, with minimal migration and upgrades. For the development team, less modification and refactoring work, reducing the risk of code migration and maintenance.
My version: https://github.com/apache/grails-core/pull/14084 My comments on James' version: https://github.com/apache/grails-core/pull/14080 On 2025/03/22 04:25:40 James Daugherty wrote: > Michael: can you give a reasons to why you disagree? > > On Fri, Mar 21, 2025 at 11:00 PM Michael Yan <rainbo...@apache.org> wrote: > > > [-1]，specifically, I disagree with 1, 2, 10 > > > > On Sat, Mar 22, 2025 at 6:02 AM James Daugherty > > <jdaughe...@jdresources.net.invalid> wrote: > > > > > Hi Everyone, > > > > > > As per the [DISCUSS] thread[1], I'd like to propose that we move forward > > > with the maven coordinate changes so we can begin snapshot builds under > > the > > > ASF namespace. > > > > > > I've done my best to capture everyone's feedback under the pull request > > for > > > this proposal here: > > > https://github.com/apache/grails-core/pull/14080 > > > > > > To view the rendered markdown file you can see it here: > > > > > > > > https://github.com/apache/grails-core/blob/d6cfcaeeba6b5db814a4a4f656782926c65fb47c/RENAME.md > > > > > > This proposal includes moving the grails-view gradle plugins under the > > > grails-gradle-plugin repository. > > > > > > The markdown file also captures how we determined this proposal by > > adding a > > > section `Package Rules`. For reference, they are restated here: > > > > > > 1. For Grails applications, the group used should always be > > > `org.apache.grails`. > > > 2. Any group that is further nested is an implementation detail of > > Grails. > > > While users can choose to override them, they are typically not meant to > > be > > > included in a Grails app directly. > > > 3. Testing artifacts for Grails applications / plugins, will have the > > > prefix `grails-testing-support-` to remind developers these artifacts > > > should not typically be included in the `implementation` scope of their > > > application. > > > 4. Gradle plugins will be consolidated under a single [repository]( > > > https://github.com/apache/grails-gradle-plugin). > > > 5. As part of the gradle plugin consolidation, we adopt consistent names > > > and remove `views-` from the views gradle plugins. Instead they will > > match > > > the existing gradle plugin naming pattern - i.e. `grails-gsp`, > > > `grails-markup`, etc. > > > 5. There will be one artifact published that can be included in either a > > > `buildSrc/build.gradle` or a `buildScript` to import all Grails gradle > > > plugins. That plugin will be `org.apache.grails:grails-gradle-plugins`. > > > 6. Grails artifacts should be prefixed with `grails-` with the exception > > of > > > profiles. > > > 7. Profiles will not use a `grails-` prefix because they are not > > > distributed with an application. > > > 8. Because there are many modern JSON implementations, and Grails may > > > choose to implement them in the future, we will refer to our existing > > > `.gson` implementation as `gson` instead of `json`. > > > 9. We have appended `-cli` where a CLI is being provided. > > > 10. Several artifacts have been renamed for clarity. In general we use > > the > > > suffix `-core` to signify a base project and drop the suffix on the > > package > > > that the end user will use. > > > 11. Package names, artifact ids, and group ids will use the plural form. > > > Implementing classes will use the singular form. > > > * For example: `org.apache.grails.events:grails-events` with the > > > `EventBusPlugin` > > > > > > > > > The vote is open for the next 72 hours and passes if a majority of at > > > least three +1 votes are cast. > > > > > > [ ] +1 proceed with the proposal > > > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > > > [ ] -1 Do not proceed because ... > > > > > > Here is my vote: > > > > > > +1 > > > > > > -James > > > > > > [1] https://lists.apache.org/thread/bk2n5wmyfywr9sff6dpngm9453jtdtcp > > > > > >
