apache/maven · warning
Plugin {} issue(s):
Error message
Plugin {} issue(s): What it means
VERBOSE report section header grouping plugin-level (not mojo-level) issues by IssueLocality: INTERNAL means the problem originates in the plugin artifact itself (descriptor, its own dependencies), EXTERNAL means it originates in how the plugin's dependencies interact with the build. One such header is printed for every locality that actually has issues, followed by one ' * issue' line each.
Source
Thrown at impl/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:244
for (Map.Entry<String, PluginValidationIssues> entry : sortedEntries) {
PluginValidationIssues issues = entry.getValue();
if (!hasAnythingToReport(issues, issueLocalitiesToReport)) {
continue;
}
logger.warn(" * {}", entry.getKey());
if (validationReportLevel == ValidationReportLevel.VERBOSE) {
if (!issues.pluginDeclarations.isEmpty()) {
logger.warn(" Declared at location(s):");
for (String pluginDeclaration : issues.pluginDeclarations) {
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);
}
}
}View on GitHub (pinned to e4093d4e12)
Solutions
- Read the issues under the INTERNAL/EXTERNAL heading: INTERNAL issues must be fixed in the plugin itself, EXTERNAL ones often by upgrading or excluding plugin dependencies
- Upgrade the plugin to a release whose dependency tree no longer triggers the finding (check with mvn dependency:tree on the plugin or its release notes)
- For in-house plugins, fix scopes (provided for maven-core) or descriptor fields, then release and bump
Defensive patterns
Strategy: validation
Validate before calling
mvn -q dependency:resolve-plugins -Dmaven.plugin.validation=verbose
Prevention
- Learn the INTERNAL vs EXTERNAL split: fix INTERNAL in the plugin, EXTERNAL usually via upgrade or dependency fixes
- Track upstream plugin releases - locality findings are usually resolved by version bumps
When it happens
Trigger: -Dmaven.plugin.validation=verbose build where issues.pluginIssues contains a non-empty set for a locality in issueLocalitiesToReport (all localities for verbose/summary, only EXTERNAL for brief).
Common situations: Plugins shipping maven-core or other Maven internals with compile scope (classic EXTERNAL finding); plugins with malformed plugin.xml metadata (INTERNAL); distinguishing whether you or the plugin author must fix the finding.
Related errors
AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21).
Data as JSON: /api/errors/bf24a1fc5fca8370.
Report an issue: GitHub.