Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <51A3458B.4080201@zeus.net.au>
Date: Mon, 27 May 2013 21:37:47 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Heads-up - Trying out Maven and git for the container.
References: <1369643300.9475.263.camel@cameron>
 <60D33702-580A-4080-ABA3-A2A0EED0EBDE@gmail.com>
In-Reply-To: <60D33702-580A-4080-ABA3-A2A0EED0EBDE@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>>
>>