jamesfredley commented on PR #15959: URL: https://github.com/apache/grails-core/pull/15959#issuecomment-4997825974
You're right that we have split packages - I verified it against the source tree. The same package is declared across multiple published jars in at least: - `org.grails.plugins.web.taglib` -> **4 modules** (`grails-gsp`, `grails-layout`, `grails-sitemesh3`, `grails-web-gsp-taglib`) - `org.grails.events` -> `grails-events-core`, `grails-events-transforms` - `org.grails.events.spring` -> `grails-events`, `grails-events-spring` - `org.grails.async.transform.internal` -> `grails-async`, `grails-async-core` Those genuinely break module-path consumption - a consumer placing these jars on the module path hits "package X in both module A and module B" - so the concern about advertising a JPMS readiness we don't have is valid. One scope clarification for the record: `Automatic-Module-Name` only stabilizes the module *name* (versus the volatile filename-derived automatic name); it doesn't itself create or enforce the split-package rule, and those packages already break module-path use today regardless of this PR. The pre-release review (Google Doc 6.2) framed automatic module names as a low-risk manifest step and full `module-info` (which would *expose* split packages) as later work. But your point that a stable module name signals module-path intent stands. Given that, I think the right call is your (a): **defer this until the split-package modules are repackaged**, rather than shipping mixed signals. The alternative - adding `Automatic-Module-Name` only to the clean majority and explicitly excluding the split-package modules (the gsp/layout/sitemesh3/taglib set, events*, async*) - is possible but muddier. I'll hold/close this PR and instead open a tracked task for the split-package repackaging, which is the real prerequisite. Sound right? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
