apache/maven · warning · DependencyResolverException

Cannot read module information.

Error message

Cannot read module information.

What it means

DefaultDependencyResolverResult.warningForFilenameBasedAutomodules() inspects the artifacts placed on the Java module path (JavaPathType.MODULES) to warn when a jar is used as an automatic module derived only from its filename. It must open each jar's module descriptor; an IOException during that read is wrapped in DependencyResolverException('Cannot read module information.'). The failure is environmental (unreadable/missing file), not a resolution problem.

Source

Thrown at impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultDependencyResolverResult.java:484

    /**
     * Returns the module name for the given value of the {@link PathModularization#descriptors} map.
     */
    private static String name(final Object value) {
        if (value instanceof String string) {
            return string;
        } else if (value instanceof ModuleDescriptor moduleDescriptor) {
            return moduleDescriptor.name();
        } else {
            return null;
        }
    }

    @Override
    public Optional<String> warningForFilenameBasedAutomodules() {
        try {
            return cache.warningForFilenameBasedAutomodules(dispatchedPaths.get(JavaPathType.MODULES));
        } catch (IOException e) {
            throw new DependencyResolverException("Cannot read module information.", e);
        }
    }
}

View on GitHub (pinned to e4093d4e12)

Solutions

1. Identify the failing jar from the IOException in getCause(), then delete that artifact directory from the local repository and re-resolve so it is re-downloaded
2. Ensure the process has read permissions and no external process locks the local repository files
3. If the warning is optional for your flow, guard the call and degrade gracefully instead of aborting the build

Example fix

// before
Optional<String> warning = result.warningForFilenameBasedAutomodules();

// after
Optional<String> warning;
try {
    warning = result.warningForFilenameBasedAutomodules();
} catch (DependencyResolverException e) {
    log.warn('Could not inspect module info: ' + e.getCause().getMessage());
    warning = Optional.empty();
}

for (Path p : dispatchedPaths.get(JavaPathType.MODULES)) {
    if (!Files.isReadable(p)) {
        throw new IllegalStateException('Module path entry not readable: ' + p);
    }
}

try {
    Optional<String> warning = result.warningForFilenameBasedAutomodules();
} catch (DependencyResolverException e) {
    // optional diagnostic: degrade to empty warning, log the IOException cause
}

When it happens

Trigger: Calling result.warningForFilenameBasedAutomodules() after a resolve that produced MODULES-path entries, when one of those jar files was deleted, locked, truncated, or has no read permission at the moment the method opens it.

Common situations: Local repository corrupted or pruned concurrently by another build/IDE; antivirus or file locking on Windows; a jar replaced by a directory of the same name in the local repo; long-running processes resolving then reading much later while the cache is cleaned.

Related errors

• Error copying POM to the local repository.
• Range defies version ordering: {}
• Cannot read metadata from '{}': {}
• Error installing metadata: {}
• Unable to prompt

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