maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "darren hartford (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MEAR-40) Autodetect "Client Application" modules and "EJB3" modules.
Date Wed, 07 Nov 2007 14:47:35 GMT

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

darren hartford commented on MEAR-40:
-------------------------------------

wow - nov 2006?  This would be nice, and help avoid the dreaded "Artifact[ejb3:*.*.*] is not
a dependency of the project."

> 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.3.2
>
>
> 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

       

Mime
View raw message