On Feb 19, 2014, at 8:43 PM, Dennis Reedy <dennis.re...@gmail.com> wrote:
> > On Feb 19, 2014, at 624PM, Greg Trasuk <tras...@stratuscom.com> wrote: >> >> I’m not sure if we should leave River-435 open to discuss the service >> packaging. > > I think we should continue this discussion, lets leave it open. > OK, so on the topic of the jar file naming conventions (hello-api.jar, hello-proxy.jar, hello-impl.jar, etc), I thought we had already adopted that as a recommended convention. It follows common “good practices” that most of us have used for a long time, and it allows you to build without ‘classdepandjar’. As well, it happens to dovetail nicely with a Maven build. Having said that, I don’t believe that convention needs to be mentioned in the single-archive packaging spec (or at least not required - I suppose it could be referenced as good practice). The spec differentiates between “class path” and “codebase” jars by having them in different folders inside the deployment archive (lib and lib-dl). So, while the build that creates the archive may very well use the conventions to determine which dependent files go into which folder, from the container’s point of view, it doesn’t care about the naming conventions. Basically, everything in the ‘lib’ dir gets included in the service’s class path, and everything in the ‘lib-dl’ dir gets published through the codebase server and included in the service’s codebase annotation. In fact, a service may want to include other jar files in either its codebase or class path (for instance domain objects). These other jar files shouldn’t be forced into a River convention, especially since that might require renaming or repackaging the jar files. > Regards > > Dennis Cheers, Greg Trasuk
