Thanks, that is the part I could not get from reading your source. if there is a choice of not offering a solution or doing some "hacky" stuff we all know what will be chosen Agreed, and I did not mean the m2e override as a reproach. Reading it is what made me look at NetBeans and IntelliJ, and finding the same construct three times is what turned this from a bug report into a question about our extension surface.
Your answer also covers the question Romain raised in parallel — whether IDEs need an in-process hook at all or could work through a daemon-style remoting protocol. "m2e could move to a leaner model, but not for free, and it would need work on the plugin side" is a much more useful answer than my guess, and the Maven 3 + 4 legacy is a cost I had not weighted properly. Your jar-plugin issue [1] is the same shape one layer up: m2e reflects into the mojo because "generate the manifest" and "package a jar" are fused, and your proposed fix is to expose that granularity in the lifecycle rather than to open a hook into the mojo. That is exactly the move I would like here — not "let IDEs override the resolver", but let a WorkspaceReader declare whether it participates in plugin resolution, so the distinction becomes a property of the supported model instead of something to be worked around. Which also means I am not asking for an "IDE aware SPI" in the large sense you sketched. Something that big would indeed need effort nobody has volunteered. The two concrete cases we have in front of us both look small. [1] https://github.com/apache/maven-jar-plugin/issues/586 Regards, Gerd > On 8. Sep 2026, at 08:35, Christoph Läubrich <[email protected]> wrote: > > Main point (from m2e developer side ;-) is that maven was never made nor > prioritized for being used in an IDE. Still users demand it and if there is a > choice of not offering a solution or doing some "hacky" stuff we all know > what will be chosen. > > To be fair there are far more things that can easily break, depending on deep > of integration and of course there are things that have worked in the past > and likely no one keeps track of them or want to change them for no reason so > they often stay (and keep working). > > Also m2e has the problem that is completely driven by volunteers - no one > "pays" for it (even though demands are often even higher) and it has chosen > an integration that goes beyond simple maven cli integration (or smth a > daemon right now offers out of the box). I'm always trying to work towards a > more lean model but this will then require more work on the maven-plugin side > what always is often not top priority of plugin authors. > > Then always there is some kind of legacy, so saying Maven 4 will do it better > does not really helps - it actually complicates things as Maven 4 can't > directly execute older Maven 3 projects - so actually one would need to be > able to support Maven 3+4 (what is an nightmare on its own) and the regular > Maven 3.x releases go in the same direction that people just don't simply > upgrade and even if there are still old branches that often has to be > maintained for a long time. > > Then it comes that IDEs life-cycles does not map nicely to what IDE demands, > e.g. you usually have no regular "test" or "package" phase (it is more > individually triggered) but maven depends on it, see for example [1]. Also > here some things changed in Maven 4 but we can't simply cut all 3.x users for > no good reason. > > So yes an "IDE Aware" SPI would be great (and Maven 4 is going already that > path slightly) but requires a lot of efforts most of the time is not wanted > or can not be offered (for free) and still often does not solve the problem > of legacy - but this is something shared with other build tools as well, none > of them are designed as IDE integration first citizen. > > best > Christoph > > [1] https://github.com/apache/maven-jar-plugin/issues/586 > > Am 07.09.26 um 21:17 schrieb Gerd Aschemann: >> 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 > > > --------------------------------------------------------------------- > 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
