Can't say I'm surprised. "internal" is just an 8 letter string like any other 8 letter string. public means public. Hyrum's Law applies.
On Mon, Sep 7, 2026 at 7:18 PM Gerd Aschemann <[email protected]> wrote: > > Hi all, > > While chasing the rc-6 IntelliJ breakage I ran into something I think > deserves a separate discussion. The immediate bug is small and already has a > fix — #13068 <https://github.com/apache/maven/issues/13068> / PR #13069 > <https://github.com/apache/maven/pull/13069>: rc-6 added two abstract methods > to the internal PluginDependenciesResolver, which breaks out-of-tree > implementations with AbstractMethodError, and making them default restores > compatibility. > > The trigger was Apache PLC4X becoming unusable in IntelliJ, reported by > Christofer Dutz on their dev list ("[DISCUSS] Downgrade to maven 4 RC-5?" > <https://lists.apache.org/thread/pkry4orbrl5nndnocgwzk6l5137tkyzp>), who also > verified the fix. Guillaume root-caused it in reply to Sergey Chernov's -1 on > the rc-6 vote > <https://lists.apache.org/thread/mtt7kg632lfs2hxcx0nv9bn4omkgbvt6>. > > The question I would like to raise is why that broke anything at all. > > Three IDEs override the same internal component > > IDE Class How > IntelliJ IDEA Maven40PluginDependenciesResolver > <https://github.com/JetBrains/intellij-community/blob/master/plugins/maven/maven40-server-impl/src/com/intellij/maven/server/m40/utils/Maven40PluginDependenciesResolver.java> > implements the interface, @Priority(10) > Eclipse m2e EclipsePluginDependenciesResolver > <https://github.com/eclipse-m2e/m2e-core/blob/main/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/EclipsePluginDependenciesResolver.java> > extends DefaultPluginDependenciesResolver > NetBeans NbPluginDependenciesResolver > <https://github.com/apache/netbeans/blob/master/java/maven.embedder/src/org/netbeans/modules/maven/embedder/impl/NbPluginDependenciesResolver.java> > extends DefaultPluginDependenciesResolver > That is every major Java IDE, independently, on an interface whose javadoc > says it "can be changed or deleted without prior notice". > > Two of the three do it for the identical reason: workspace resolution must > not apply to plugin resolution. Resolver's WorkspaceReader is session-scoped > with no plugin-versus-dependency distinction, so the only way to say "resolve > plugins from the repository, not from my workspace" is to wrap our component > and toggle the reader around the call. m2e disables > EclipseWorkspaceArtifactRepository, NetBeans calls > NbWorkspaceReader.silence(). IntelliJ's case is thinner — a retry decorator > around our own implementation. > > m2e's source still carries the citation: > > Plugin realms are cached and there is currently no way to purge cached realms > due to MNG-4194. Workspace plugins cannot be cached, so we disable this until > MNG-4194 is fixed. > MNG-4194 is #5961 <https://github.com/apache/maven/issues/5961>, "API to > safely release of plugin realms", opened in 2009 and closed in 2010 with the > comment "Now working correctly in M2E". An API request, closed because the > consumer's workaround worked. Sixteen years later the workaround is still > there, in three products. > > Maven 4 offers no alternative > > org.apache.maven.api.spi > <https://github.com/apache/maven/tree/maven-4.0.x/api/maven-api-spi/src/main/java/org/apache/maven/api/spi> > currently contains ExtensibleEnumProvider, LanguageProvider, > LifecycleProvider, ModelParser, ModelTransformer, PackagingProvider, > PathScopeProvider, ProjectScopeProvider, PropertyContributor, TypeProvider > and SpiService. All of it concerns the model, the lifecycle and the type > system. Nothing touches artifact or plugin resolution. > > So an embedder that needs to influence resolution has exactly one door, and > it is the one we reserve the right to close without notice. We then did > change it, mid-RC-vote, and IntelliJ broke for every user of a project that > declares core extensions. > > Possible directions > > I am not attached to any of these; I would like to know which one the project > considers right. > > Document the contract instead of adding API: state that plugin and extension > resolution bypasses the WorkspaceReader. If that is the intended behaviour > anyway, two of the three overrides disappear. > Make the distinction expressible — a session or request scoped flag, or a > separate workspace reader for plugin resolution. > A minimal supported SPI for plugin/extension resolution. > Decide explicitly that embedders are on their own. That is a legitimate > answer — Maven 4 deliberately shrank its public surface, and a resolution > SPI is a real maintenance commitment. But then I think we should say so > plainly, rather than leave one internal door ajar and let three IDEs walk > through it for fifteen years. > Whatever we choose, adding methods to a widely implemented interface as > default rather than abstract costs us nothing and avoids this class of > breakage — that part is just hygiene. > > On timing: I am explicitly not proposing this as a 4.0.0 blocker — the fix > in PR #13069 is what 4.0.0 needs. But I would not want to rule 4.0.0 out > either. If the answer turns out to be option 1, or a very small additive SPI, > it may be worth weighing whether it still fits before GA rather than waiting > for 4.1 — an addition made after GA is harder to place than one made with > it. That judgement is the project's, not mine. > > Input from the IDE side would be worth more than my reading of their source. > Marit van Dijk, Nikita Skvortsov, Sergey Chernov (JetBrains) what do you > actually need from Maven here, and would option 1 or 2 be enough to let you > drop the override? The same question to whoever is closest to m2e and > NetBeans. > > Regards, > Gerd > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 -- [email protected] -- https://aschemann.net > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
