elharo commented on issue #179: URL: https://github.com/apache/maven-ear-plugin/issues/179#issuecomment-5103914663
per gemini this represents a legitimate bug in the plugin (a regression), not a user error. Here is the technical breakdown of why this is a bug: **The Mechanism of the Failure** Normally, a WAR file's internal dependencies (`WEB-INF/lib`) are managed and packaged by the `maven-war-plugin`. However, the `maven-ear-plugin` has features designed to intercept and repackage these modules at the EAR level to prevent duplication. Specifically, the EAR plugin can strip redundant libraries out of the enclosed WARs and move them to the EAR's shared library directory (traditionally using the `skinnyWars` configuration). **The Regression in 3.2.0** Version 3.2.0 of the `maven-ear-plugin` introduced major architectural changes to how it handles dependency exclusion, notably implementing the `skinnyModules` parameter which extended the WAR-stripping logic to other module types. When the user upgraded from 3.1.0 to 3.2.0 without changing their POM configuration, the `ejb-client` dependency (the Camunda client in the reporter's case) was silently stripped from the WAR file during the EAR packaging phase. This indicates that the changes to the module-stripping logic in 3.2.0 either: 1. Incorrectly flag `ejb-client` types for exclusion from the WAR regardless of the user's `skinnyWars` configuration. 2. Fail to properly remap or copy the excluded `ejb-client` to the EAR's shared library directory if a skinny configuration is active. **Conclusion** A minor version upgrade of a build plugin must maintain backward compatibility regarding dependency inclusion semantics. Because the plugin is actively and silently modifying the WAR payload in a way that differs from the 3.1.0 baseline—leading to a runtime `ClassNotFoundException` or similar dependency failures—this is a valid defect in the plugin's artifact resolution and packaging logic. -- 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]
