------------------------ Guillaume Nodet
Le mer. 7 août 2024 à 13:24, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-08-07 à 12 h 55, Guillaume Nodet a écrit : > > > I'm not a big fan of reducing the visibility of implementation > > classes. The API is well defined, i.e. all org.apache.maven.api.* > > packages. > > > It is because while the API does not expose Eclipse Aether, the > implementation does. If, in the future, we want to reduce the amount of > wrapping, we will need to evaluate the consequence of that change, and > having the implementation classes publicly accessible makes that > evaluation more difficult. 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…. > > Anyway, I don't really see where the problem can be, as for plugins, > > the default setup should only expose the org.apache.maven.api > > packages, so they won't even have access to implementation classes. We > > just need to merge https://github.com/apache/maven/pull/1336 > > > If PR #1336 has the effect of making the implementation classes > inaccessible outside Maven core, then removing some "public" keywords > would not change the situation for plugins and would have the advantage > of clarity, isn't it? 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). Anyway, that was just an opinion, as I’ve needed more than once to workaround such good designs patterns, and that’s really painful. I don’t really oppose, I’m just not really seeing the benefits. > > Martin > >
