No, services shouldn't be required to use this standard but the River-provided services should model it as the best practice, as mentioned in another thread.
-j On Wed, Feb 19, 2014 at 6:05 PM, 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 > > >
