Seems reasonable, as long as we tackle it piecewise. Going back to the original purpose, we need a home for @Experimental. We can put that in gemfire-common and create a separate issue for gemfire-junit -> gemfire-test and associated code movement.
Anthony > On Sep 12, 2015, at 11:16 AM, Kirk Lund <[email protected]> wrote: > > I'm pretty sure we could rename gemfire-junit to gemfire-test. > gemfire-junit was named only because of gemfire-test existing in a > different repo. > > Currently, all of our reusable testing utilities/classes/rules are under > src/test/java in either gemfire-junit or gemfire-core (dunit is all under > the latter because it depends on DistributedSystem). This placement is a > hold-over from the old build structure. > > I think creating a library of test common is a good idea and the testing > classes would probably move from src/test/java into src/main/java and then > be assembled into a jar (such as gemfire-test-common.jar). Is that the > general idea? > > All of our dependencies on gemfire-junit are currently other subprojects > depending on its build dir which contains the classes from its > src/test/java (hence no jar). > > gemfire-common (reusable non-test-related components) > gemfire-test (reusable test-related components) > > gemfire-core currently has more reusable test-related components than > gemfire-junit, but all of these (including Annotations, custom Rules, etc) > are currently under src/test/java as well. If we're going to clean up > gemfire-junit(test) and move its classes from src/test/java (except the > tests) to src/main/java then we should do the same for dunit and other > reusable test-related components in gemfire-core as well. > > -Kirk > > On Sat, Sep 12, 2015 at 10:34 AM, Jacob Barrett <[email protected]> wrote: > >> You don't want runtime libraries and test time libraries in the same jar. >> Putting junit utility and annotation classes that would only be used in >> junits in a jar that would have to be included in a production class path >> is broken. Gemfire-common.jar would imply something common to gemfire at >> runtime, like string utils, logging, and other cross cutting runtime >> concerns. >> >> >> >> >> If you want a library for common test classes then think >> gemfire-test-common.jar or something. >> >> >> >> >> Jacob Barrett >> Manager >> GemFire Advanced Customer Engineering (ACE) >> Pivotal >> >> [email protected] >> 503-533-3763 >> >> For immediate support please contact Pivotal Support at >> http://support.pivotal.io/ >> >> On Sat, Sep 12, 2015 at 7:04 AM, Anthony Baker <[email protected]> wrote: >> >>> Annotations are utilities…? The gemfire-junit name seems unnecessarily >> restrictive. Currently it only contains annotations related to junit tests. >>> Hadoop defines both hadoop-annotations and hadoop-common. >>> Anthony >>>> On Sep 11, 2015, at 9:08 PM, Jacob Barrett <[email protected]> wrote: >>>> >>>> -1 >>>> >>>> >>>> >>>> >>>> Reserve common for things common to geode development not related to >> unit testing. Like utilities classes. >>>> >>>> >>>> >>>> >>>> Jacob Barrett >>>> Manager >>>> GemFire Advanced Customer Engineering (ACE) >>>> Pivotal >>>> >>>> [email protected] >>>> 503-533-3763 >>>> >>>> For immediate support please contact Pivotal Support at >> http://support.pivotal.io/ >>>> >>>> On Fri, Sep 11, 2015 at 12:04 PM, Kirk Lund <[email protected]> >> wrote: >>>> >>>>> I filed ticket GEODE-327 to propose renaming gemfire-junit to >>>>> gemfire-common. >>>>> We'd like to be able to define common annotations in this >> gemfire-common >>>>> and not be limited to code that is specific to junit or testing. The >> first >>>>> annotation would be Experimental (see GEODE-328). >>>>> Please vote on making this change. >>>>> Thanks, >>>>> Kirk >>
