Derived automatic module name validation fails builds for non-modular projects since 3.4.2

[gnodet]

Problem

maven-jar-plugin 3.4.2 validates the derived automatic module name (inferred from the artifact's Automatic-Module-Name manifest attribute or from the artifactId) even when it is not explicitly configured in the POM. If the derived name contains hyphens (which are not valid in Java module names), the build fails:

Error assembling JAR: Invalid automatic module name: 'org.apache.geronimo.arthur.integration-test'

This was not enforced in maven-jar-plugin 3.3.1. The stricter validation was introduced via maven-archiver in 3.4.2.

The check isValidModuleName() in maven-archiver's MavenArchiver now validates the derived module name, but many legitimate Apache projects have artifact IDs containing hyphens (e.g. integration-test, osgi-cdi) which produce invalid module names when derived mechanically. These projects do not intend to be JPMS modules and have no module-info.java.

Steps to reproduce

1. Build a project whose artifactId (or Automatic-Module-Name manifest entry) contains a hyphen, e.g. my-artifact-integration-test.
2. Use maven-jar-plugin 3.4.2.
3. Build fails with Error assembling JAR: Invalid automatic module name: '...'.

Expected behavior

One of:

• Only validate explicitly declared names: If Automatic-Module-Name is not set explicitly in the POM's <archive><manifestEntries>, do not fail — the derived name is merely informational for unnamed modules and does not need to be a valid JPMS module name.
• Warn instead of fail: Emit a warning so the project is aware of the problem without breaking the build.

Affected versions

• 3.4.2 (regression vs 3.3.1)

Context

Found while running Maven 4 compatibility tests across Apache projects. Affected projects include:

• geronimo-arthur — derived name org.apache.geronimo.arthur.integration-test
• incubator-kie-kogito-benchmarks — empty derived name
• karaf-winegrower — derived name org.apache.winegrower.cepages.winegrower-cepage-osgi-cdi

None of these projects declare module-info.java or intend to be named JPMS modules.

[desruisseaux]

If the module name is not valid, then it seems to me that the manifest should not contain Automatic-Module-Name at all. What would be the purpose of this attribute if not for using the JAR on the module-path? (even if the project that provides this attribute is not itself modular).

[gnodet]

Actually, the right fix is to sanitize the name rather than omit it entirely.

When the JDK encounters a non-modular JAR without Automatic-Module-Name on the module path, it derives a name from the JAR filename using a well-defined algorithm. When the attribute is present, it uses it as-is — throwing if it's invalid. So a manifest with an invalid Automatic-Module-Name is actually worse than no attribute at all.

Omitting the attribute restores the filename-derived fallback, which is reasonable — but we can do better: apply the same sanitization the JDK would have applied to the filename, so the JAR gets a predictable, stable, named automatic module. That's what the project intended when setting the attribute.

For org.apache.geronimo.arthur.integration-test, the sanitized name is org.apache.geronimo.arthur.integration.test. No consumer could have been depending on the original invalid name (the JDK would have rejected it), so this is a safe improvement.

Updated the PR accordingly: apache/maven-archiver#402