Howdy, not a "solution" but just to throw another bone: Takari Lifecycle had (somewhat similar) support for this since 2010s: http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
But instead of forcing this onto publishers (to specify is something "api" or "implementation"), lifecycle enforced this at the consumer side, basically preventing you to depend (by mistake) on transitive class. IF you want to compile against it, you MUST specify it as dependency, "pulling" it level above in your dependency tree. Personally, I love this feature, as it helps you prevent many potential issues and those are all discovered build time. T On Fri, Mar 7, 2025 at 10:00 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > > Hi all, > > While I do like the simple rules of Maven 3 scopes[1], I often lack the > flexibility that Gradle's `api` and `implementation`[2] configurations > provide. > > With the separation of build and consumer POMs it should be probably be > easy to have some `compile` dependencies in the build POM become > `runtime` dependencies in the consumer POM. What do you think? Should > such a feature be provided by Maven Core or a plugin? Are there any APIs > in Maven 4 that allow a plugin to change the scope a dependency will > have in the consumer POM? > > Looking at POM snippets that users show us in issue reports or on > StackOverflow, I find that the average user has already a problem in > understanding the existing scopes. For example most users put > `log4j-core` as `compile` dependency instead of `runtime`, even if they > don't reference it in their code. Adding yet another distinction in > Maven Core might be confusing, so I am rather thinking about > implementing it in a plugin. > > Another argument for using a plugin is that it is hard to decide if a > dependency is `api` or `implementation`, without using a binary tool. We > already use the BND Maven Plugin to handle our OSGi "uses" and JPMS > "transitive" directives, so it would make sense to implement the `api` > vs `implementation` in the same tool. > > Piotr > > [1] Except the functionally equivalent `provided` scope and `optional` > qualifier. These are source of interminable discussions on which one > should be used. > > [2] > https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
