Hi, before looking for a solution why are they assuming "workspace resolution must not apply to plugin resolution", lot of projects had been done this way and until we do provide a "build project" like solution it is the way to extend the build, ie have a plugin in the reactor. I know it has side effects (or constraints) but it is the only option we do have today so it must be supported.
Underlying question is: do they need anything at all, can't we ensure IDE integration is as smooth as having an efficient listener (collector/reporter) in an reusable process (mvnd or alike with remoting protocol which surfaces way less than the API/internals)? Now I agree with Eliotte, we worked hard to have an API/SPI in maven 4 so if used and not there we let it run cause we are cool but we could blow up in terms of contract ;). Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le lun. 7 sept. 2026 à 21:54, Elliotte Rusty Harold <[email protected]> a écrit : > 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 <+49%20173%203264070> -- [email protected] -- > https://aschemann.net > > > > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
