any chance of getting maven into this? jason
On Mon, Feb 28, 2011 at 8:29 PM, Patricia Shanahan <[email protected]> wrote: > On 2/27/2011 11:19 PM, Peter Firmstone wrote: > >> 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. >> > > The issue I'm trying to understand is not the release of production code, > but the issue of how to organize benchmarks that need to be run in order to > decide whether to make a change. Depending on the benchmark result, the > change may not happen at all. > > Patricia >
