Hi Gerd, thank you for bringing this up! I dug into our solution and found that these retries did not cover a specific use case. They fixed some flaky issues in our own tests. I think we should remove them and find a better solution.
However, we are well aware that our heavy use of internal APIs makes IntelliJ IDEA's integration fragile. Broken IDEA support for Maven 4.0-rc-6 is a good showcase. We would be happy to discuss possible improvements around IDE integrations with the community. The biggest gap between the IDE and CLI experience lies in failure handling. For a command line tool it is important to fail as soon as possible, but the IDE needs the opposite: to reconstruct as much as possible while being as resilient as possible. To achieve this in IntelliJ IDEA, we went quite far, calling many internal Maven components directly and customizing the overall initialization. --- Nikita Skvortsov Java Build Tools Team Lead JetBrains N.V. | KvK reg. nr. 56460279 Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19 E: [email protected] On Tue, 8 Sept 2026 at 11:57, Gerd Aschemann <[email protected]> wrote: > Nice, that objection lands — I had the framing wrong, and correcting it > makes the ask much smaller. > > > before looking for a solution why are they assuming "workspace resolution > > must not apply to plugin resolution" > > Short recap so we are talking about the same thing. `WorkspaceReader` is > set > once per `RepositorySystemSession`. Maven's own `ReactorReader` and, when > present, the `@Named("ide")` reader are chained into it via > `MavenChainedWorkspaceReader`. `DefaultPluginDependenciesResolver` derives > its > session from the build session and keeps that reader, so plugin resolution > consults exactly the same chain as dependency resolution. > > You are right that this is a feature, not an accident: a plugin module in > the > reactor has to be usable in the same build. So "plugin resolution bypasses > the > WorkspaceReader" — my option 1 — is not a clarification, it is a behaviour > change. I withdraw it. > > What the IDEs probably need is narrower than I made it sound. It is not > plugins versus > dependencies; it is that *different readers have different validity for > plugin > resolution*. The ReactorReader should apply. An IDE workspace reader should > not — m2e's code still explains why, citing MNG-4194: plugin realms are > cached > and cannot be purged, so a plugin served from the IDE workspace leaves a > stale > realm executing old code. > > Both end up in one session-scoped chain, and that distinction cannot be > expressed today. So the smallest useful change may be to let a > `WorkspaceReader` declare whether it participates in plugin resolution. > That is > additive, leaves CLI behaviour untouched, and would let all three IDEs > drop the > override entirely. Note we already have the plug point — `@Named("ide")` — > we > just cannot scope it. > > For the JetBrains folks: would that be enough for you to drop > `Maven40PluginDependenciesResolver`, or does the retry it wraps need > something > else? > > Regards, > Gerd > > > On 7. Sep 2026, at 22:54, Romain Manni-Bucau <[email protected]> > wrote: > > > > 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> <+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] > >> > >> > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 <+49%20173%203264070> -- [email protected] -- > https://aschemann.net > >
