[ 
http://jira.codehaus.org/browse/MEAR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MEAR-40.
-------------------------------

    Resolution: Duplicate

Fixed with MEAR-137

> 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
>            Assignee: Stephane Nicoll
>             Fix For: 2.6
>
>
> 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


Reply via email to