The Java EE spec provides no (supported) way for stand-alone modules to depend on other JARs such as the 3rd-party one you are using. You'd need to resort to an EAR to do that.
I guess it seems a little less odd to me than to you about packaging JARs that support the client into the EAR. I view the EAR as a packaging artifact including what's needed for all modules including clients, not just what's needed for the server-side components. Plus, considering that GlassFish will need to serve the JARs for Java Web Start support, even client-side-only JARs will need to be deployed to the server anyway.
As for the ACC, the spec and the GlassFish implementation of it make no assumptions about what U/I technology clients will use. The role of the ACC is to provide client-side Java EE services to app clients so the developer can focus on the business needs rather than, for example, managing security or transactions or naming look-ups. That's why the ACC views themes and layout managers as part of the application rather than as part of the Java EE infrastructure. This means, of course, that to provide a layout manager or theme (at least one that's not part of the Java SE platform) you'll need to package them into the EAR.
You have a valid point that it's a bit cumbersome to redeploy the entire app if only the U/I has changed. If that's likely to happen frequently while back-end changes are rare, you could take another approach. Deploy two applications, a server-side-only EAR (with the remote interfaces and any other required supporting classes and interfaces in one JAR and the EJB implementations and supporting cast in the EJB module) and a separate client-side-only EAR containing the app client and its support libraries AND the JAR containing the remote interface for the EJBs which the client will use. This approach would let you deploy U/I changes separately from any back-end changes, but with the added complexity of incorporating the JAR containing the remote interface for the EJBs into the client app as well as the server one. You'd need to choose which approach is the lesser of two evils given your situation.
- Tim
[Message sent by forum member 'tjquinn' (timothy.quinn_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=379703