ascheman opened a new pull request, #13069:
URL: https://github.com/apache/maven/pull/13069

   ## Summary
   
   Fixes #13068.
   
   4.0.0-rc-6 added `resolveCoreExtensionAndFlatten` and 
`resolvePluginAndFlatten` to the internal `PluginDependenciesResolver` as 
**abstract** methods (#12335). Implementations that live out of tree — IntelliJ 
IDEA, Eclipse m2e, NetBeans all have one — are compiled against a different 
Maven than they run on, so the first plugin resolution dies with 
`AbstractMethodError`.
   
   This is the fix @gnodet announced for rc-7 [in reply to the rc-6 
vote](https://lists.apache.org/thread/mtt7kg632lfs2hxcx0nv9bn4omkgbvt6).
   
   ## Change
   
   Both methods become `default` and delegate to the pre-existing 
`resolvePlugin`, which `DefaultPluginDependenciesResolver` already treats as an 
alias — there, `resolvePlugin` delegates to `resolvePluginAndFlatten`.
   
   `resolvePlugin` stays abstract on purpose: giving it a default too would let 
an implementation that overrides neither method recurse infinitely. There is an 
`@implSpec` note warning against delegating back.
   
   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`. If 
you would rather not guess there, I am happy to make it throw 
`UnsupportedOperationException`; say the word.
   
   ## Tests
   
   **Unit** — `PluginDependenciesResolverDefaultMethodsTest`:
   
   * a resolver implementing exactly the pre-forward-port method set; its 
compiling *is* the compatibility assertion
   * both defaults asserted to delegate to `resolvePlugin` with the expected 
arguments
   * a `Method.isDefault()` guard, so re-abstracting either method fails the 
build
   
   **Integration** — `MavenITgh13068LegacyPluginDependenciesResolverTest`: 
builds a core extension that overrides `PluginDependenciesResolver` with only 
the pre-rc-6 method set, deliberately compiled against `maven-core:4.0.0-rc-5`, 
installs it, and runs a build that uses it via `.mvn/extensions.xml`. It 
asserts an error-free build *and* two marker lines, so it cannot pass without 
actually exercising the extension.
   
   Both were verified red without the change. Reverting only the interface 
gives:
   
   ```
   Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 <<< FAILURE!
   Caused by: java.lang.AbstractMethodError: Receiver class
     org.apache.maven.its.gh13068.LegacyPluginDependenciesResolver does not 
define or inherit
     an implementation of the resolved method 'abstract ... 
resolvePluginAndFlatten(...)'
     at 
DefaultMavenPluginManager.createPluginRealm(DefaultMavenPluginManager.java:421)
   ```
   
   ## Real-world verification
   
   @chrisdutz confirmed that a `maven-4.0.x` build carrying this patch imports 
Apache PLC4X in IntelliJ IDEA cleanly, where stock rc-6 produces a cascade of 
errors. PLC4X is affected via `resolveCoreExtensionAndFlatten` because it 
declares core extensions in `.mvn/extensions.xml`.
   
   Worth noting the JetBrains side does not make this unnecessary: 
`resolveCoreExtensionAndFlatten` is implemented only on their master and is 
absent from IntelliJ IDEA 2026.2.2, the current release.
   
   ## Note on the base branch
   
   This targets `maven-4.0.x` because that is where the regression shipped and 
where rc-7 / GA come from. Happy to open the equivalent against `master` first 
if you prefer that order — the change applies unmodified, the baselines are 
identical.
   


-- 
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