[goutamadwant]

Fixes #1230.

A Maven 4 mojo can declare an @Resolution field, but Plugin Tools currently omits it from plugin.xml. Maven then leaves the field null even when the project has matching dependencies.

This change carries the annotated field, pathScope, and requestType through scanning and descriptor generation, including fields inherited from a superclass. It writes <resolutions> only for Maven 4 descriptors. The v4api-4x integration test checks the generated XML and runs a mojo with direct and inherited resolution fields against a real compile dependency.

Validation:

• On unmodified master with Maven 4.0.0-rc-7, the plugin builds, but the descriptor has no <resolutions> and goal execution fails because the compile dependency was not injected.
• The targeted v4api-4x integration test passes with Maven 4.0.0-rc-7 after the fix.
• mvn -Prun-its verify passes with Maven 3.9.16 and JDK 21: 32 plugin integration tests pass, one Maven 4 fixture is skipped under Maven 3, and 12 plugin-report integration tests pass.
• git diff --check passes.

---

To make clear that you license your contribution under the Apache License Version 2.0, January 2004, check one of the following:

• I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004.
• I hereby declare that I have filed an Apache Individual Contributor License Agreement.

[gnodet-bot]

Two low-severity findings in the new @Resolution support:

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[goutamadwant]

@gnodet-bot addressedc both review comments: ResolutionAnnotationContent now has a useful toString(), and the descriptor omits <requestType> when the annotation uses its empty default.. Let me know if any comments/suggestions!

[gnodet-bot]

Review of PR #1234: Fix Maven 4 @resolution injection in generated plugin descriptors

This is a re-review of the updated commits (head SHA 85655a16).

Previous review findings are addressed. Three low-severity Javadoc gaps remain in the new public API on ExtendedMojoDescriptor:

Findings:

1. addResolution() missing Javadoc — The pre-existing addAfterLink() method directly above has @param and @since 4.0.0 documentation. addResolution() should be consistent.

2. getResolutions() incomplete Javadoc — The single-line /** Returns the Maven 4 resolution injections declared by this mojo. */ is missing @return and @since 4.0.0 tags, which are present on the analogous getAfterLinks().

3. ResolutionEntry inner class missing @since 4.0.0 and toString() — The class-level Javadoc lacks @since. The inner AfterLink class (pre-existing) has toString() for debuggability; ResolutionEntry should too.

Additionally: no unit test covers the collectResolutions() hierarchy traversal semantics — only an IT was added. And equals()/hashCode() on ExtendedMojoDescriptor don't include resolutions, mirroring the pre-existing gap for afterLinks (non-blocking).

Verdict: The feature logic looks correct. The Javadoc gaps are minor but worth fixing before merge for API consistency.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[goutamadwant]

@gnodet-bot addressed the three API documentation and toString() comments. I also added a hierarchy unit test and made the descriptor omit an empty pathScope. Please let me know if you see anything else.

[gnodet-bot]

Following up on my earlier review — all 5 findings have been addressed in the latest commits.

• ✅ toString() added to ResolutionAnnotationContent
• ✅ Empty <requestType/> XML emission fixed (conditional guard in PluginDescriptorFilesGenerator)
• ✅ addResolution() Javadoc added with @param and @since 4.0.0
• ✅ getResolutions() Javadoc completed with @return and @since 4.0.0
• ✅ ResolutionEntry inner class now carries @since 4.0.0 and toString()

LGTM.

This review was generated by an AI agent, Hermès on behalf of @gnodet.