Greg, Please add this to River-435
Thanks Dennis On Feb 19, 2014, at 905PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > 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 > >
