Le 2024-08-07 à 14 h 21, Guillaume Nodet a écrit :

Why do we care ? If we provide a well defined API (with a known set of jars), people should be aware if they use maven-core jar directly….

It is a matter of reputation for the Maven project. A Murphy law is that given a sufficiently large amount of users, everything accessible will be depended upon by someone somewhere, no matter the warnings that we provide. Sun Microsystems and Oracle suffered from that Murphy law with libraries depending on Java implementation details, and developers blaming Sun or Oracle when those details changed. It forced Oracle to handle some of Java internal almost as if they were public API (e.g., the Unsafe class). I think that it is one of the motivations for blocking accesses to internal packages in JPMS. Another reason is probably security.

Maven does not have as many users as Java, so its exposition to above Murphy law may be lower, but I have the impression that Maven has a better compatibility record than Gradle (i.e., better chances that a plugin working with a Maven version continues to work with the next version). Reducing the visibility of implementation classes increases the chances to keep a plugin ecosystem that way.


Right, but I would think a follow-up PR would allow importing additional packages from the maven realm (or even hide some). Hiding may be needed in some very specific cases (I’ m thinking mainly about hiding slf4j in case the plugin embeds a library which relies on a specific logging provider).

Side note: those goals with Realm look very similar to JPMS… For example, the use case with SLF4J is a non-transitive dependency in JPMS ("transitive" here does not have the same meaning as in Maven). I was thinking, after completion of all the work for improving JPMS support in Maven, to try on a branch to modularize Maven itself just for checking if it is possible. If the latter case appears feasible, it is not clear to me why using Realm?

    Martin

Reply via email to