Hiteshsai007 commented on PR #12745: URL: https://github.com/apache/maven/pull/12745#issuecomment-5314190950
Hi @desruisseaux, thank you for the feedback! The primary goal here is to establish strict compile-time isolation at the build-tool level, mirroring the distinction Gradle makes between `api` and `implementation` scopes. While it's absolutely true that a library *needs* its internal dependencies on the classpath to function (which is why both `compile` and `api` scopes are provided at **runtime**), a consumer compiling *against* that library does not need those internal dependencies leaked onto its **compile classpath**. If project `A` depends on `B`, and `B` uses an internal utility `C`, leaking `C` onto `A`'s compile classpath is dangerous. It allows `A` to accidentally import and use classes from `C` directly. If `B` later updates and swaps out `C` for a different library, `A`'s compilation will break. While the Java Module System (`requires` vs `requires transitive`) handles this elegantly, a massive portion of the Java ecosystem still does not use JPMS modules. This change brings that same level of strict encapsulation to Maven's dependency management for all projects. By making `compile` non-transitive (equivalent to Gradle's `implementation`), dependencies are correctly placed on the runtime classpath but omitted from the consumer's compile classpath. When a library explicitly *does* expose a dependency in its public method signatures, developers can use the new `api` scope, which remains fully transitive across both classpaths. -- 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]
