Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 2.2
-
Fix Version/s: 2.6
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
The J2EE 1.4 specification know the modules type "EJB", "WEB", "RAR" and "Client Application".
The EAR plugin currently supports the autodetection of "EJB", "WEB" and "RAR".
As a result, the EAR plugin automatically creates an application.xml file containing <module> entries using the corresponding type, without the need to add <module> entries to the pom.
Unfortunately this is not working with "Client Application" modules and "EJB3" modules.
To have a client module's corresponding <java> tag get added to the application.xml file, the developer has to add it to the pom.xml manually, what is not nice. Actually it would be easy for the EAR plugin to do that automatically: It just needs to check whether each of the dependencies named in the pom.xml file has a ".jar" extension AND contains a file called "/META-INF/client-application.xml" (check J2EE 1.4 specification chapter 9 on details). If such a file is found, the dependency is a "Client Application" and in turn the EAR plugin has to add a "<java>" tag to the application.xml file.
Also, the support of "EJB3" modules is not working, since they do not necessarily have a "/META-INF/ejb-jar.xml" file contained, which would be needed to discriminate "utility JARs" from "EJB3 JARs" (as the distinction of "utility JARs" from "Client Application JARs" can be done as described above using the existence of the "/META-INF/client-application.xml" file). Nevertheless, there should be a means of automatic detection of EJB3 modules for automatic generation of <module> entries in application.xml. A possible way to solve that could be to analyze the content of each file with a .jar extension: As soon as at least one class is contained that is annotated as @Stateful, @Stateless, @Entity or @MessageDriven, or as soon as a file named "/META-INF/ejb-jar.xml" is found in the jar, the definitively is an EJB module and in turn the EAR module has to add a <ejb> tag to the application.xml file. Actually this will slow down detection of module types, but on the other hand the user decided to use the automation instead of manually adding <module> entries, so he will accept the performance penalty.
Issue Links
| This issue is related to: | ||||
| MEAR-46 | Ejb clients are not included in the generated application.xml - JavaModule is confusing |
|
|
|
OK for your first comment regarding client-application.
For the other comment it has nothing to do with the EAR plugin. If you have an EJB3 artifact declared with an 'ejb' dependency it will work out of the book. Don't expect maven to recognize ejb3 modules if you define them as simple jar. However, if the ejb plugin prevents you from building an Ejb if no ejb-jar.xml is found, please raise an issue in this plugin.