Yes we really should standardise these conventions, Dennis, have you had
any thoughts about doing some standards docs?
I'd also like to see Rivers deployment jars be updated to follow these
conventions.
Regards,
Peter.
On 27/05/2013 9:29 PM, Dennis Reedy wrote:
Greg,
You could take a look at what I've done with Rio and the recommended
conventions http://www.rio-project.org/conventions.html. FWIW, most of what you
outline below (sans surrogate) is what we've been doing with Rio, you should
check it out (or fork it on github :)).
Regards
Dennis
On May 27, 2013, at 428AM, Greg Trasuk wrote:
Hi all:
As you know, I've been working for some time on a container for Jini
services. This work started out as a Surrogate container, but has
migrated to be a generic container that has similar goals to the old
Harvester project on jini.org. To wit:
- Provide a simplified deployment environment (simpler than the
com.sun.jini.Start mechanism)
- Host multiple services in one VM. e.g. reggie plus business
services.
- Handle the task of serving codebase jars without asking much of the
developer
- Handle the classpath without asking much of the developer.
- Provide a platform on which to develop better deployment standards
- Provide an implementation of the Surrogate spec.
- Allow for service containers on one machine, by auto-allocating
codebase ports
The work has been contained up to now in the jtsk/skunk/surrogate
branch. It has reached a point of relative feature-completeness where
I'm now comfortable inviting review and participation from other River
developers.
In light of recent discussions about git I thought I'd try it out, so
I've moved the bulk of the project into a git repository at
git://github.com/trasukg/river-container. Eventually of course, the
nascent Apache git server will hold the canonical copy.
At the same time I'm migrating to Maven. Here's where I need the
services of someone a little more experienced with Maven than I am.
Could someone tell me if I'm on the right or wrong track?
I've setup a multi-module project like so:
river-container - parent project
--river-container-core - Java and associated source for the core
container
The core jar files need to get assembled with configuration files and
dependent jars into a deployment layout similar to JBoss or Tomcat.
Services get assembled and packaged into a jar file somewhat like a web
application. For integration testing, I need to assemble a test
container including reggie and the core container components, and so on.
So I'm thinking that I'll add the following modules to the multi-module
project:
-- reggie-module.ssar - Starter Service Archive module for reggie
-- river-container-test - container configured with Reggie for testing
-- river-container-default - container configured for basic use.
Does that make sense? Should the Maven group id be "org.apache.river"
or "org.apache.river.container"?
Feel free to have a look and let me know.
Greg.
