[MEAR-305] skipClassPathModification sets Class-Path empty

[jira-importer]

Philippe Marschall opened MEAR-305 and commented

We upgraded from version 3.0.1 to version 3.2.0 of the plugin. We use EJB JARs in an ear and configure defaultLibBundleDir. Our EJB JARs come with Class-Path headers in the manifest which must not be modified.
Version 3.2.0 of the EAR plugin modified Class-Path headers of the EJB JARs so we configured <skipClassPathModification>true</skipClassPathModification> however this still results in the Class-Path headers of the EJB JARs being modified and set to empty.

---

Affects: 3.2.0

Issue Links:

• MEAR-292 skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf
  ("is caused by")

[elharo]

a legitimate bug in the plugin, not a user error. This is a regression tied to the 3.2.0 release.

Here is the technical breakdown of the defect:

The Expected Behavior
In Java EE/Jakarta EE deployments, standard modules like EJB JARs often contain custom MANIFEST.MF files with a predefined Class-Path attribute to link to utility libraries. The maven-ear-plugin provides a configuration flag, <skipClassPathModification>true</skipClassPathModification>, which is explicitly designed to instruct the plugin to leave these manifests untouched during the EAR packaging phase.

The Bug Mechanism
When the user upgraded to version 3.2.0, they found that the plugin was modifying their EJB JAR manifests. To stop this, they correctly applied the <skipClassPathModification>true</skipClassPathModification> configuration.

However, instead of bypassing the manifest manipulation logic entirely, the plugin still rewrote the MANIFEST.MF file but cleared the existing Class-Path attribute, resulting in an empty classpath. This strips the EJB JAR of its required runtime dependencies, leading to ClassNotFoundException errors during deployment.

The Root Cause
The issue tracker notes this bug was caused by a previous fix: MEAR-292 ("skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf").

In attempting to fix MEAR-292 (which likely addressed a scenario where the plugin was injecting a Class-Path header into modules that didn't want one), the developers altered the manifest handling logic. The resulting logic incorrectly nullifies or overwrites existing Class-Path entries when the skip flag is set, rather than simply preserving the original manifest state.

Because the provided configuration behaves exactly contrary to its documented purpose—destroying data rather than preserving it—this is definitively a bug.