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> -- [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 -- [email protected] -- https://aschemann.net
