What I think is important is that any java code should be in a Java source file that is compiled as part of a build. Don't put java source or bytecode in as resource or as a constant.
For testing deploy jar I thought what Helena and I ended up doing in StartServerCommandDUnitTest worked pretty well - build a jar from a class on the classpath: File jar = temporaryFolder.newFile(jarName); new ClassBuilder().writeJarFromClass(RunOutOfMemoryFunction.class, jar); -Dan On Fri, Oct 12, 2018 at 3:32 PM Patrick Rhomberg <prhomb...@apache.org> wrote: > 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. >
