The package might be always a problem. Even you put the cq benchmark code under geode-cq to near its source code, it might still have to access code under other package, such as geode-core.
So I think put benchmark test code under benchmark package is ok. Your option 2) is good. Regards Gester On Fri, Jan 5, 2018 at 11:57 AM, Nick Reich <nre...@pivotal.io> wrote: > Team, > > I am in the progress of adding new benchmarks to the (currently sparse) > geode-benchmarks module. The lack of current examples in the module leads > me to wonder what the correct organization of benchmarks in the module is > (and if this is the right location). > > The existing benchmarks are all in org.apache.geode.cache.benchmark. > Following this pattern would (presumably) result in benchmark subpackages > in each package that has benchmarks. Making the root package > org.apache.geode.benchmark would remove this proliferation of sub packages. > However, both these approaches have the issue that package level > methods/classes cannot be accessed from benchmarks as they will never share > a package with the production code. > > 1) Should benchmarks then not be put in special benchmark packages? > > 2) Should our benchmarks not invoke package level methods/classes in the > case that we should use benchmark packages? Or should such benchmarks not > reside in the benchmarks module? > > 3) Is geode-benchmarks where we intend all benchmarks, only certain classes > of benchmarks (all using jmh for example), or would we prefer embedding > them in the modules where the code being benchmarked resides? > > Thanks for your input. >
