[MEAR-303] Problem when using EJBClient in an EAR

[jira-importer]

Berry Holtrust opened MEAR-303 and commented

Hello,

 

When trying to upgrade the EAR plugin from version 3.1.0 to 3.2.0, I'm running into a problem with the packaging of an EJB dependency. I've created a sample project to show the issue. I'm using a 'core' module with EJB packaging and a web module packaged as a WAR, all wrapped up in an EAR. Additionally, this is a Camunda project and deployed to a WildFly Camunda instance, version 7.9.0. If I build the EAR using plugin version 3.1.0, I get the Camunda ejb-client dependency inside the WAR and everything works just fine. After upgrading to version 3.2.0 of the EAR plugin, this dependency is missing and it stops working. That's the only difference I've been able to find in the real project.

 

I'm not sure if this is a bug or a mistake in the plugin configuration, but I've not been able to get it to package as I would expect. Any help would be appreciated!

 

Here is the sample project: https://github.com/berryh/CamundaEJBMavenEarPluginBugDemo

---

Affects: 3.2.0

[elharo]

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.