I understand your concerns, but as a Jave EE server very well knows what a RAR is good for and how it is structured, it should be able to provide the interface JAR without the need for physical duplication. In the end, to make this clear to the server, this is the sole reason for the complexity of RAR packaging.
> -----Original Message----- > From: Laird Nelson [mailto:[email protected]] > Sent: Montag, 25. Juni 2012 15:49 > To: Maven Users List > Subject: Re: How to correctly make an EJB module dependend of the > interface JAR of a RAR? > > On Mon, Jun 25, 2012 at 2:27 AM, Markus Karg <[email protected]> wrote: > > > Any other opinions? Any solutions? I cannot believe that an EAR must > > not only contain the RAR but also a duplicate (!) of the RA' public > interface. > > > Recall that a .rar can be deployed as a standalone module, consumable > by other modules (including .ears) on the application server. A .rar's > public interface could therefore be required both by the .rar itself > (to provide an appropriate connection factory, etc.), and by the > callers in some .ear somewhere that use it. That is, I believe, the > rationale for the interface duplication. > > For my resource adapters, I have three small Maven projects: > * The public API project. This is basically interfaces only. It > depends on nothing. > * A "jca" project. This is the logic of the resource adapter. It > depends solely on the public API and the JCA classes (provided scope). > * A "rar" project. This is packaging only and depends on the other > two. > > In my .ear file (for application-scoped .rars, which is what you're > talking about, which makes deployment with GlassFish very difficult, > incidentally, but that's a side issue), I include the public API > project as a runtime dependency (it ends up in the lib directory) and > the rar project as a <type>rar</type> runtime dependency (it ends up at > the root level). > > Best, > Laird > > -- > http://about.me/lairdnelson --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
