ascheman opened a new pull request, #1000: URL: https://github.com/apache/maven-enforcer/pull/1000
Implements the `banSplitPackages` rule proposed in #997 — the follow-up announced in #996. > [!IMPORTANT] > **Stacked on #996.** The first four commits are #996 (module-info reader + three rules); only the top three commits (`feat` / `test` / `docs` for `banSplitPackages`) are new here. Once #996 merges I will rebase onto master and the diff collapses to just the new rule. Draft until then. ## Rule A package must belong to exactly one Java module — two modules on the module path containing the same package fail resolution (`java.lang.module.ResolutionException`), typically at packaging, `jlink`, or first boot, with a symptom-not-cause message. And if the offending module is not even `requires`d, the resolver never pulls it in: the build stays green while a type or endpoint is silently absent at runtime. - **Project packages** come from **walking the output directory**, not the compiled descriptor — `ModulePackages` is only finalized at packaging time, and offending classes are frequently added *after* compile (code generation, copied resources). Both the classic layout and the **Maven 4 module source hierarchy** are supported (same `moduleOutputs()` discovery as #996). - **Dependency packages** are read through `java.lang.module.ModuleFinder` (reflectively — same Java 8 baseline rationale as the reader in #996), which derives automatic-module names and reports complete package sets; artifacts the finder cannot model fall back to a plain class-file scan. - The rule intersects against the **full declared-dependency set**, deliberately not only the `requires`d modules — this is what catches the silent variant. - **Severity model:** overlap between two artifacts that both end up on the module path → **error**. An automatic module counts as "on the module path" only when a project module actually `requires` its derived name. Overlaps involving a classpath-only artifact are legal today and reported at `<classpathSeverity>` (default `warn`) as a modularization hazard. - **Configuration:** `classpathSeverity` (`warn`/`error`/`ignore`), `allowedSplitPackages`, `ignoredModules`, `ignoredArtifacts`, `message`. - **Non-goal:** a provider that is not a declared Maven dependency (pure runtime) is out of scope. The rule is a safety net, not a fix — the durable cure is placing generated/copied classes in the module that owns their package. ## Design note: dependency resolution `ResolverUtil` is widened to `public`: the `enforce` mojo declares only `requiresDependencyCollection`, so artifact *files* are not resolved by default; the rule resolves them explicitly — the same approach `enforceBytecodeVersion` already uses. ## Tests - 15 unit tests (Java 9+ gated; ASM fixtures in test scope only, extended with a JAR fixture writer for explicit/automatic/plain dependency artifacts). - Four ITs under `maven-enforcer-plugin/src/it/projects/`: a classic two-artifact reactor failing on the silent variant, a clean pass, a classpath-overlap warn case (build succeeds, warning names the automatic module), and a Maven 4 module-source-hierarchy fail case (gated `4.0.0-rc-5+` / JDK 17+). - Full `mvn clean verify -P run-its` green on Maven 3.10.0-rc-1 (158 ITs passed); the four new ITs additionally verified on Maven 4.0.0-rc-5. --- - [x] Your pull request should address just one issue, without pulling in other changes. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. - [x] Run `mvn verify` to make sure basic checks pass. - [x] You have run the integration tests successfully (`mvn -Prun-its verify`). - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) (Replaces #999, which GitHub auto-closed when the head branch was renamed to `feature/997-ban-split-packages`.) -- 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]
