ascheman opened a new issue, #13068:
URL: https://github.com/apache/maven/issues/13068

   ### Affected version
   
   4.0.0-rc-6, and current `master` / `maven-4.0.x`
   
   ### Bug description
   
   4.0.0-rc-6 added two **abstract** methods to 
`org.apache.maven.plugin.internal.PluginDependenciesResolver`, forward-porting 
the Maven 3.10.0 changes (#12335 / #12329, eaa575e89 / c1de26776):
   
   * `resolveCoreExtensionAndFlatten(Plugin, DependencyFilter, 
List<RemoteRepository>, RepositorySystemSession)`
   * `resolvePluginAndFlatten(Plugin, Artifact, DependencyFilter, 
List<RemoteRepository>, RepositorySystemSession)`
   
   Confirmed with `javap` against the shipped distributions: rc-5 declares 
three methods on this interface, rc-6 declares five.
   
   That interface is documented as internal. It is nevertheless implemented out 
of tree by **every** major Java IDE, because implementations are compiled 
against one Maven and run against another, adding abstract methods to it 
produces `AbstractMethodError` on the first plugin resolution:
   
   | IDE | class | how |
   | --- | --- | --- |
   | IntelliJ IDEA | `Maven40PluginDependenciesResolver` | implements the 
interface, `@Priority(10)` |
   | Eclipse m2e | `EclipsePluginDependenciesResolver` | extends 
`DefaultPluginDependenciesResolver` |
   | NetBeans | `NbPluginDependenciesResolver` | extends 
`DefaultPluginDependenciesResolver` |
   
   m2e and NetBeans subclass the default implementation and therefore inherit 
the new methods; IntelliJ implements the interface directly and breaks. @gnodet 
root-caused this on 2026-08-01 in reply to @seregamorph's `-1` on the [rc-6 
vote](https://lists.apache.org/thread/mtt7kg632lfs2hxcx0nv9bn4omkgbvt6) and 
announced `default` implementations for rc-7; this issue is the tracking ticket 
for that, with a PR attached.
   
   #### User impact, concretely
   
   Apache PLC4X moved its baseline to rc-6 and became unbuildable in IntelliJ — 
@chrisdutz raised ["[DISCUSS] Downgrade to maven 4 
RC-5?"](https://lists.apache.org/thread/pkry4orbrl5nndnocgwzk6l5137tkyzp) on 
their dev list, where the project discussed pinning back to rc-5.
   
   The reason it hits PLC4X hard is `resolveCoreExtensionAndFlatten`, which 
resolves **core extensions**, and PLC4X declares extensions in 
`.mvn/extensions.xml`. @chrisdutz has verified that a build of `maven-4.0.x` 
carrying the patch below imports PLC4X cleanly in IntelliJ, where stock rc-6 
produces a cascade of errors. (Chris, feel free to confirm here in your own 
words.)
   
   Note the JetBrains side is only half solved and cannot be relied on: 
`resolvePluginAndFlatten` was fixed on their `262` branch on 2026-06-26 and 
ships since 2026.2 GA, but `resolveCoreExtensionAndFlatten` exists **only on 
their master** (2026-07-30, 2026-08-05) and was not backported. IntelliJ IDEA 
2026.2.2 (build 262.10315.125, released 2026-09-02) still does not implement it 
— verified against the shipped `maven40-server.jar`, not just the tracker. So 
users on the current IntelliJ release depend on the Maven-side fix.
   
   #### Reproduction
   
   Compile a `PluginDependenciesResolver` implementation against 4.0.0-rc-5, 
then invoke the new methods with rc-6 on the classpath — the same 
compile-against-one / run-against-another situation an IDE embedder is in:
   
   ```
   [control ] resolvePlugin                  -> OK
   [subject ] resolvePluginAndFlatten        -> AbstractMethodError
   [subject ] resolveCoreExtensionAndFlatten -> AbstractMethodError
   ```
   
   The control call, present in both versions, succeeds. The attached PR 
contains this as a real core IT.
   
   #### Proposed fix
   
   Make both methods `default`, delegating to the pre-existing `resolvePlugin`, 
which `DefaultPluginDependenciesResolver` already treats as an alias (there, 
`resolvePlugin` delegates to `resolvePluginAndFlatten`). `resolvePlugin` stays 
abstract deliberately: a default there would let an implementation overriding 
neither method recurse infinitely.
   
   The default for `resolveCoreExtensionAndFlatten` is documented as best 
effort — a dedicated implementation additionally reads the extension's artifact 
descriptor to apply relocations and run `MavenPluginDependenciesValidator`. 
Happy to make it throw `UnsupportedOperationException` instead if you prefer 
not to guess there.
   
   #### Beyond this fix
   
   The narrow fix restores compatibility, but the underlying reason three IDEs 
override an internal component is that Maven 4 offers no supported extension 
point for plugin or extension resolution — `org.apache.maven.api.spi` covers 
model, lifecycle and types only. m2e and NetBeans both override it for the same 
purpose: suppressing workspace resolution for plugins. m2e's code still cites 
MNG-4194 (#5961, opened 2009, closed 2010 with "Now working correctly in M2E") 
as the reason.
   
   That is a separate discussion and should not block this fix; I intend to 
raise it on dev@.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to