[
http://jira.codehaus.org/browse/MEAR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177478#action_177478
]
Brian Leathem commented on MEAR-40:
-----------------------------------
Thanks, I now see that the status is still: Open.
I was looking in the comments (All) where it said:
{quote}
Stephane Nicoll made changes - 22/Feb/09 03:43 AM
Fix Version/s 2.3.2 [ 13023 ]
Fix Version/s 2.4 [ 14487 ]
{quote}
Which I interpreted as meaning it was supposed to be fixed in version 2.4. I
guess I misunderstood.
I've added my vote to the issue, as I'm working around this by manually writing
the application.xml file for my ear. This is un-ideal, as I have to remember
to edit it every time I do a release (since the version numbers change).
> 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
