[
http://jira.codehaus.org/browse/MEAR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177230#action_177230
]
Brian Leathem commented on MEAR-40:
-----------------------------------
{quote}
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.
{quote}
This issue is marked as fixed, but I am not getting the quoted behaviour. I
have an ear project that has a dependency on a jar that contains an
"application-client.xml" file (I also tried using the filename
"client-application.xml" as in the above quote). The ear's application.xml
file has entries for the ejb and web modules, but not for the application
client module. This is for a JavaEE 5 project.
I am using maven 2.10. So should this issue still be open? Is there some
other way of including my application-client in the ear file?
Thanks,
Brian Leathem
> 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.4
>
>
> 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
