river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: [Discuss] Please have a look at the River Container
Date Thu, 20 Feb 2014 02:33:14 GMT

Please add this to River-435



On Feb 19, 2014, at 905PM, Greg Trasuk <trasukg@stratuscom.com> wrote:

> On Feb 19, 2014, at 8:43 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>> On Feb 19, 2014, at 624PM, Greg Trasuk <trasukg@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

View raw message