elharo commented on issue #180:
URL:
https://github.com/apache/maven-ear-plugin/issues/180#issuecomment-5103930497
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
