[ http://jira.codehaus.org/browse/MEAR-40?page=comments#action_77205 ] Stephane Nicoll commented on MEAR-40: -------------------------------------
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. > Autodetect "Client Application" modules and "EJB3" modules. > ----------------------------------------------------------- > > Key: MEAR-40 > URL: http://jira.codehaus.org/browse/MEAR-40 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature > Affects Versions: 2.2 > Reporter: Markus KARG > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
