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]
