apache/maven · warning

Mojo {} issue(s):

Error message

  Mojo {} issue(s):

What it means

VERBOSE report section header for mojo-level issues, grouped by IssueLocality. Unlike plugin-level findings, these were reported per mojo (PluginValidationManager.reportPluginMojoValidationIssue) - typically API misuse inside a specific mojo class rather than the plugin's packaging. One header per locality with issues, each followed by ' * Mojo ...' entries.

Source

Thrown at impl/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:255

                            logger.warn("   * {}", pluginDeclaration);
                        }
                    }
                    if (!issues.pluginIssues.isEmpty()) {
                        for (IssueLocality issueLocality : issueLocalitiesToReport) {
                            Set<String> pluginIssues = issues.pluginIssues.get(issueLocality);
                            if (pluginIssues != null && !pluginIssues.isEmpty()) {
                                logger.warn("  Plugin {} issue(s):", issueLocality);
                                for (String pluginIssue : pluginIssues) {
                                    logger.warn("   * {}", pluginIssue);
                                }
                            }
                        }
                    }
                    if (!issues.mojoIssues.isEmpty()) {
                        for (IssueLocality issueLocality : issueLocalitiesToReport) {
                            Map<String, LinkedHashSet<String>> mojoIssues = issues.mojoIssues.get(issueLocality);
                            if (mojoIssues != null && !mojoIssues.isEmpty()) {
                                logger.warn("  Mojo {} issue(s):", issueLocality);
                                for (String mojoInfo : mojoIssues.keySet()) {
                                    logger.warn("   * Mojo {}", mojoInfo);
                                    for (String mojoIssue : mojoIssues.get(mojoInfo)) {
                                        logger.warn("     - {}", mojoIssue);
                                    }
                                }
                            }
                        }
                    }
                    logger.warn("");
                }
            }
            logger.warn("");
            if (validationReportLevel == ValidationReportLevel.VERBOSE) {
                logger.warn(
                        "Fix reported issues by adjusting plugin configuration or by upgrading above listed plugins. If no upgrade available, please notify plugin maintainers about reported issues.");
            }
            logger.warn(

View on GitHub (pinned to e4093d4e12)

Solutions

  1. Identify the mojo under the header and either avoid that goal, or upgrade the plugin to a release where the mojo was fixed
  2. For in-house plugins, refactor the flagged mojo (replace deprecated API calls, use the injected Session) and release
  3. Waive with maven.plugin.validation.excludes if the mojo cannot be changed and the risk is accepted
Defensive patterns

Strategy: validation

Validate before calling

mvn clean install -Dmaven.plugin.validation=verbose  # mojo-level findings need verbose, not summary

Prevention

When it happens

Trigger: -Dmaven.plugin.validation=verbose build where issues.mojoIssues has a non-empty map for a locality; populated when a mojo execution triggered per-mojo checks (deprecated API usage, missing annotations).

Common situations: Older mojos calling removed/Deprecated Mojo API methods (e.g. the no-arg execute variants or Session/ getSession misuse); plugins where only some goals are problematic.

Related errors


AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21). Data as JSON: /api/errors/d61bcc969c04e2a1. Report an issue: GitHub.