-1. Maven is complex enough (really too complex) already. Anything that makes it more so feels unwise. I doubt this feature would carry its weight at this late point in time.
I'm also extremely skeptical of efforts to build new language level features like a separation between API and implementation anywhere other than the JDK itself. And finally I think that splitting impl and api packages is usually bad design. This most often signals that the developers are improperly using Java's own access protection mechanisms, In particular they're liking committing one to all of these sins: 1. Spreading code and API across too many packages 2. Not doing test first development 3. Using Java interfaces where they should be using classes 4. Making methods and classes public that shouldn't be On Fri, Mar 7, 2025 at 9: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 > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
