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
