ascheman commented on issue #997: URL: https://github.com/apache/maven-enforcer/issues/997#issuecomment-5574467352
> Why do we need an enforcer rule for this? IN cases where it matters, the JDK takes care of it. @elharo — fair challenge, and partly true: for the **loud** case (two modules with the same package on the module path) the JVM does reject it, at jlink/boot, with a `ResolutionException`. There the rule isn't net-new detection — it's *earlier and clearer*: it fails at `verify`, before packaging/jlink, naming the offending package and **both** owning artifacts, instead of a cryptic resolver error the *consumer* hits at first boot. A library author who builds on the classpath never sees it — their downstream module-path user does. Two things the JDK does **not** cover: 1. **The silent split.** The rule intersects the project's packages against *every declared dependency*, not only the `requires`d ones — so it flags a package your output shares with a dependency the module graph never resolves: a green build today that breaks the moment a consumer actually pulls that module in. The resolver can't catch this because it never loads the second module. 2. **Classpath → module-path migration.** On the classpath a split package is legal and silent (first-found-wins; the JVM never complains). As an opt-in classpath lint (`warn` by default) the rule surfaces those landmines while the build is still green — a "module-readiness" check, not just a module-path guard. There's prior art for this kind of build-time hygiene the JDK doesn't do: mojohaus `banDuplicateClasses` catches the same *class* in two jars (classpath). `banSplitPackages` is its module-path counterpart — the same *package* in two modules, even when there's no duplicate class (so `banDuplicateClasses` stays silent). This follow-up was foreseen from the start: the descriptor-rule family began as mojohaus/extra-enforcer-rules#361, moved into core Enforcer as #995 (`requireExplicitModules`, `requireMinimalExports`, `banUnjustifiedOpens`) at @slawekjaranowski's suggestion — and that RfE already flagged a module-path-aware split-package variant (this rule) as the natural next step. Concretely, this bit a real project ([write-up](https://vidocq.dev/posts/multi-module-jpms-apps-on-vidocq-one-opens-one-split-package-and-a-fix/)): a build-time annotation processor generated classes into a **dependency's** package but under the **consumer** module's `target/classes`, so the consumer jar claimed a foreign package → `ResolutionException` on the module path. The authoritative package set is the *output directory* — `module-info`'s `ModulePackages` is rewritten at packaging time and the offending classes are generated after `compile` — so only a build-time scan of `target/classes` catches it; inspecting the compiled descriptor doesn't. Happy to keep module-vs-module an error and the classpath case opt-in `warn`, so it's zero-noise for projects that don't care. -- 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]
