Can you explain what would we do with maven? I can't tell if you're attempting to encourage work on another item or trying to solve the benchmark challenge.
On 28 February 2011 07:31, Jason Pratt <[email protected]> wrote: > 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 > > >
