Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.217.15 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Mglpit8BvQTbKq5E6LYiLK7Xguer7weVOvjg4Eyj8A3mT+9hBOfa+4VVLjP6c6BE0w
         7kFTmIto8v/nusKbnMUBK3DzZ9VXUMQMDw4nvAczsSOYJ3GOnVq30XcZE6Y9rf4Q4mtv
         0H9d0zDWDoP/X7g3wDJTz5qG0xc/MkjvpeCbA=
Message-Id: <738AA6EC-76D1-46AC-B2B1-4721EC37B69E@gmail.com>
From: Dennis Reedy <dennis.reedy@gmail.com>
To: river-dev@incubator.apache.org
In-Reply-To: <4932FA79.1060603@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Jini Service Container advice...
Date: Sun, 30 Nov 2008 15:58:32 -0500
References: <4932FA79.1060603@gmail.com>

Hi Dan,

On Nov 30, 2008, at 341PM, Dan Rollo wrote:

> Hi All,
>
> I'm in the midst of some redesign discussions with other devs on the  
> CruiseControl project (plug link: http://cruisecontrol.sourceforge.net/distributed/index.html) 
> . ;)
>
> We have a "Distributed extension" aka: DistCC (for remote build  
> agents) that we are trying to merge into the core of the project. We  
> are also working to remove some coupling to "shared file systems"  
> that have limited our options going forward. Towards that end, I see  
> Jini as a way to keep hostname and other hardcoded network  
> configuration out of the picture.
>
> In my stumblings with Jini, I've more that once done things the  
> "wrong way", and I think I have an opportunity to use a nice "Jini  
> Container" that will do things the "right way", and protect me from  
> myself in the future. ;)
>
> While searching for such "Jini Service Containers", I have a few  
> questions about what might be the best fit:
>
> Rio
> https://rio.dev.java.net/
> This is the one I've heard the most about, but I'm a little  
> concerned about the size of it's footprint. Any thoughts here? Are  
> there smaller "rio parts" that could be deployed, without requiring  
> a ~15mb download on each client? Even if not, it's probably not a  
> show stopper, but it may be harder to get buy in...

The Rio download should not be confused with the Rio distribution  
requirements, it depends on what you need. Rio comes bundled with  
optional third party technologies that you may not need (take a look  
at the third party technologies document in the lib directory for  
details on the bundled technologies , their use and licenses). For  
example if you dont want Spring and it's required commons jars they  
can be removed, junit does not need to be included, tools jars for  
classdepandjar, etc...

Let me know if this helps or if you need more clarification. Feel free  
to send mail to users@rio.dev.java.net if you need any assistance, or  
feel free to contact me directly.

Regards

Dennis