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
