Hello, all! There are a number of classes that require some number of "toy" classes as part of their testing framework, e.g., to be used as custom data containers. Many of these classes involve testing or use of the `deploy jar` command, and so are packaged into jars for this purpose. In an effort to promote good coding habits and, as importantly, consensus throughout this community and our codebase, I would like to ask which of these are considered the preferred method to maintain these additional classes. I realize a priori that none of these options will be applicable in all cases, but am curious of how the prioritization of these options are ordered among you all.
-- Class definition -- For definition of the classes consumed, we observe all of the following in the Geode codebase. Option C-1: Toy classes are defined as a proper class in a reasonable package. -- suboption (a): The class is defined in the module in which it is consumed, as a resource. [1] -- suboption (b): The class is defined in the module in which it is consumed, as a neighboring file. [2] -- suboption (c): The class is defined in geode-dunit or geode-junit. [3] Option C-2: Toy classes are defined as inner classes of the test class. [4] Option C-3: Sufficiently small toy classes are defined as raw String fields in the test class that consumed it and is compiled by the test JVM via the JavaCompiler class. [5] -- Resource exposure -- For those tests that require classes placed in Jars for use in the `deploy jar` command, we observe the following in the Geode codebase: Option J-1: Jars are a resource and are built or downloaded as necessary during the build steps, before test execution. [6] Option J-2: Sufficiently small classes that are defined as raw String fields in the test class that consumes it (C-3 above) are packaged into resources via the JarBuilder class. [7] I look forward to hearing your opinions. Imagination is Change. ~Patrick Rhomberg Examples: [1] geode-core_test/resources:org.apache.geode.management.internal.deployment.ConcreteExtendsAbstractExtendsFunctionAdapter.java is found by the FunctionScannerTest to be a user-defined function. [2] geode-core_distributedTest:org.apache.geode.internal.cache.SerializableMonth defines a simple DataSerializable containing an int for the month, to be consumed by *.MonthBasedPartitionResolver in PRCustomPartitioningDistributedTest. [3] geode-junit_main:org.apache.geode.cache.query.transaction.Person defines a simple DataSerilazable container class for a String name and int age. [4] geode-core_distributedTest:java.org.apache.geode.internal.statistics.StatisticsDistributedTest$PubSubStats is consumed by its parent class [5] geode-assembly_acceptanceTest:org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest defines a Customer class in a raw string in the test's @Before method. [6] See our own consumption of geode-dependencies.jar et al via the StartMemberUtils.java, or our historic consumption of tools.jar [7] See again [5] or other uses of the JarBuilder class.
