Here's a vote in favour of raising the priority for this issue. Consider the following scenario:
- We have converted a large, existing application to Maven. The application uses EJB 2.1 and throughout all the EJB and WEB deployment descriptors the <ejb-link>EjbModule.jar#EJB-NAME</ejb-link> element is used for wiring everything together.
- To make the ejb-links work, we're using the <bundleFileName> directive to strip version numbers from the JARs and WARs upon inclusion in the EAR file.
- This breaks the manifest class-paths of the wars and ejb-jar's that have been included int he ear, as mentioned in the original issue. On WebSphere v5.1, this is a serious problem; correct manifest class-paths in the embedded modules are a requirement (e.g. if a WAR and EJB-JAR are are part of the same EAR, and the WAR uses the EJB's, the manifest class-path for the WAR file must mention the EJB-JAR file by its name within the EAR). The manifest class-path of the ear itself, as Stephane mentions in comment 1, isn't so important.
In my opinion, the maven-ear-plugin is justified in rewriting the manfest class-paths of its included modules on the basis that these modules become part of a larger assembly and (in that scope) no longer exist on their own. The original modules remain unchanged in the repository. Rewriting the manifest class paths is easier than rewriting the ejb-links, and has a potentially wider applicability.
We're in the process of selecting the least painful of a number of work-arounds. If the maven-ear-plugin would update the manifest classpaths for the modules it includes, that'd be mighty helpful.