Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D6B4C97.1000103@zeus.net.au>
Date: Mon, 28 Feb 2011 17:19:51 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Benchmark organization
References: <4D630533.1060301@acm.org> <4D6370E3.1000905@zeus.net.au>
 <4D63FAD3.5070404@acm.org> <4D65C1F1.5080006@zeus.net.au>
 <4D6B36F6.80204@acm.org>
In-Reply-To: <4D6B36F6.80204@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Patricia Shanahan wrote:
> On 2/23/2011 6:26 PM, Peter Firmstone wrote:
>> Patricia Shanahan wrote:
>>> On 2/22/2011 12:16 AM, Peter Firmstone wrote:
>>>> Patricia Shanahan wrote:
>>>>> I want to get going on some performance tuning, but believe it is 
>>>>> best
>>>>> guided and controlled by well-organized benchmarks. To that end, I
>>>>> propose adding a place for benchmarks to the River structure.
> ...
>> Each module would be considered a separate build, the tests would
>> include unit and integration tests. Other modules yours depends on are
>> like libraries, you wouldn't be concerned with their implementation. The
>> existing qa harness would be a separate library module (similar to how
>> junit or jtreg is a separate component). Jini Platform tests would be
>> separated from implementation tests. (We also need to consider how to
>> best utilise the discovery and join test kit.)
>>
>> If the changes are localised to your module, meaning the public API
>> doesn't change, which is like an independent build, you could just
>> duplicate the original module, modify it, then run performance tests
>> against both the new and original modules, your new module name would
>> have a different version number to reflect the experimental changes.
>>
>> If the changes to involve changing public API in the module, in a non
>> backward compatible manner, and this API is not part of net.jini.*
>> (which must remain backward compatible), then other modules that are
>> dependent can be migrated to the new module over time, proxy's that
>> utilise the new module will need to use preferred class loading to
>> ensure the correct classes are loaded. The module version number would
>> be incremented to show it is not backward compatible.
>
> How would you propose handling a case like outrigger.FastList?
>
> It is package access only, so changing its interface to the rest of 
> outrigger did not affect any public API. Several classes needed to be 
> changed to handle the interface change.
>
> Patricia
>
>
Well each module can have it's own release schedule, in this case you'd 
develop the Outrigger module, integration test it, increment its version 
and release it.  The public API hasn't changed, users can update their 
Outrigger servers and add the new proxy jar archive to their codebase 
servers, this will allow Outrigger to evolve at a faster pace than 
River's Jini Platform.  This makes our release process much faster, with 
more updates more often.

It's a lot of work to release the whole platform before users can 
download and test the new Outrigger, so having incremental module 
releases makes a lot of sense.

Each module can function in the same environment coexisting with 
previous module versions, since it is only an implementation of 
Javaspace, implementation classes will exist in separate ClassLoaders 
even in the same JVM.

Cheers,

Peter.